| Développons en Java 2.30 | |
| Copyright (C) 1999-2022 Jean-Michel DOUDOUX | (date de publication : 15/06/2022) |
|
|
 |
 |
 |
 |
| Niveau : |  Supérieur |
Le développement en Java impose certaines contraintes :
Ces facteurs allongent la durée d'apprentissage des développeurs et complexifient l'architecture des applications.
De ce fait, le concept de framework est apparu, pour l'essentiel, massivement soutenu par la communauté open-source qui est très prolifique dans le monde Java.
Ce chapitre contient plusieurs sections :
Le développement d'applications peut être facilité grâce à l'utilisation :
Le terme framework est fréquemment utilisé dans des contextes différents mais il peut être traduit par cadre de développement.
Les frameworks se présentent sous diverses formes, qui peuvent inclure tout ou partie des éléments suivants :
L'objectif d'un framework est de faciliter la mise en ouvre des fonctionnalités de son domaine d'activité. Il doit permette au développeur de se concentrer sur les tâches spécifiques de l'application à développer plutôt que sur les tâches techniques récurrentes telles que :
La mise en oeuvre d'un framework permet notamment :
Cependant, cette mise en oeuvre peut se heurter à certaines difficultés :
Le développement d'applications d'entreprise avec Java (J2EE) s'avère relativement complexe. Il est nécessaire d'assimiler de nombreux concepts et API pour pouvoir développer et déployer une application J2EE. Par exemple pour le développement d'applications web, les API et les spécifications de J2EE ne proposent qu'un support de bas niveau au travers des API Servlets et JSP.
Le développement d'une application de taille moyenne ou complexe va ainsi rencontrer d'énormes difficultés. Pour faciliter le développement et augmenter la productivité, des frameworks ont été développés.
L'intérêt de la mise en oeuvre d'un ou plusieurs frameworks a fait ses preuves depuis longtemps. Une des grandes difficultés est de sélectionner le ou les frameworks à utiliser.
L'intérêt majeur des frameworks est de proposer une structure identique pour toutes les applications qui l'utilisent et de fournir des mécanismes plus ou moins sophistiqués pour assurer des tâches communes à toutes les applications.
Il est possible de développer son propre framework mais cela représente un investissement long, risqué et donc coûteux qu'il sera quasi impossible de rentabiliser d'autant que de nombreux frameworks sont présents sur le marché dont quelques frameworks open source particulièrement matures. Par exemple, le framework Struts du groupe Apache Jakarta est devenu un quasi-standard adopté par la majorité des acteurs proposant un IDE et sert de base au développement d'autres frameworks open source ou commerciaux.
Il existe de nombreux frameworks open source dont la possibilité de mise en oeuvre concrète est très variable en fonction de plusieurs facteurs : fonctionnalités proposées, maturité du projet, évolutions constantes, documentation proposée, ...
Plusieurs d'entre-eux sont devenus de véritables succès grâce à leur adoption par de nombreux développeurs et à l'apport de nombreux contributeurs (exemple : Struts, Log4J ou Spring). Ils permettent d'avoir des frameworks relativement complets, fiables et fonctionnels. En plus, comme tout projet open source, les sources sont disponibles ce qui permet éventuellement de faire des modifications pour répondre à ses propres besoins ou ajouter des fonctionnalités.
La diversité de ces frameworks permet de répondre à de nombreux besoins. Le revers de la médaille est la difficulté de choisir celui ou ceux qui y répondront au mieux.
Pour choisir un framework, les caractéristiques suivantes doivent être prises en compte :
Le plus gros défaut des frameworks est lié à leur complexité : il faut un certain temps d'apprentissage pour avoir un minimum de maitrise et d'efficacité dans leur utilisation.
Le choix d'un framework est très important car l'utilisation d'un autre framework en remplacement impose souvent un travail important essentiellement lié à la prise en main du nouveau framework et aux adaptations ou à la réécriture partielle de morceaux de l'application.
Généralement, le coeur d'une application repose sur une architecture proposée par un framework mais il est aussi nécessaire de prévoir d'autres frameworks pour réaliser certaines tâches généralement techniques :
Ainsi, les frameworks peuvent être regroupés en plusieurs catégories :
Généralement, pour le développement d'applications, il est nécessaire de mettre en place une architecture et d'utiliser plusieurs frameworks dédiés à la mise en oeuvre des fonctionnalités auxquelles ils répondent. Cet ensemble d'entités est désigné par socle technique.
Un socle technique est donc composé d'une architecture et d'un ensemble de frameworks pour faciliter le développement des couches qui composent l'architecture (IHM, objets métiers, persistance des données, ... ) et pour proposer des services techniques transverses (logging, ...)
Les attentes dans la définition d'un socle technique sont nombreuses :
Généralement, un socle technique doit être défini spécifiquement pour les besoins de l'application ou des applications. Cependant, il est possible de s'appuyer sur un socle existant pour ne pas avoir à complètement réinventer la roue. Il existe des socles techniques open source.
Les applications web sont généralement le point d'entrée principal pour les applications développées en utilisant la plate-forme J2EE.
Pourtant le développement d'applications web est relativement compliqué à concevoir et à implémenter pour plusieurs raisons :
A ces inconvénients indépendants de la technologie côté serveur pour les mettre en oeuvre viennent s'ajouter des raisons spécifiques à la plate-forme J2EE :
Dès que l'on développe des applications web uniquement avec les API servlet et JSP, il apparait évident que de nombreuses parties dans des applications différentes sont communes mais doivent être réécrites ou réutilisées à chaque fois. Ceci est en grande partie lié au fait que les API servlets et JSP sont des API de bas niveau. Elles ne proposent par exemple rien pour automatiser l'extraction des données de la requête HTTP et mapper leur contenu dans un objet de façon fiable, assurer les transitions entre les pages selon les circonstances, ...
Les frameworks de développement web permettent généralement une séparation logique d'une application selon le concept proposé par le modèle MVC (Modèle/Vue/Contrôleur). Le framework le plus utilisé dans cette catégorie est Struts.
Certains éditeurs proposent des frameworks qui s'appuient sur un framework open source et facilitent leur utilisation en proposant des fonctionnalités dédiées dans leur IDE (Oracle ADF avec Jdeveloper, Beehive avec Weblogic Workshop, ...).
L'utilisation d'un framework web permet de faciliter le développement et la maintenance évolutive d'une application web. Les frameworks utilisent ou peuvent être complétés par des moteurs de templates qui facilitent la génération de page web à partir de modèles.
Les frameworks les plus récents (tel que Java Server Faces) mettent en oeuvre l'utilisation de composants côté serveur pour faciliter les développements (modèle événementiel et développement graphique)
Récemment, une nouvelle forme d'applications web est apparue : les applications riches. Elles peuvent prendre plusieurs formes et notamment dans les développements J2EE utiliser AJAX (reposant sur DHML pour des échanges asynchrones avec le serveur) ou Lazlo (reposant sur flash). Ces technologies rendent les applications plus riches et plus conviviales pour les rapprocher de ce que les utilisateurs connaissent avec le client lourd.
Le modèle MVC (Model View Controler) a été initialement développé pour le langage Smalltalk dans le but de mieux structurer une application avec une interface graphique.
Ce modèle est un concept d'architecture qui propose une séparation en trois entités des données, des traitements et de l'interface :
Initialement utilisé pour le développement des interfaces graphiques, ce modèle peut se transposer pour les applications web sous la forme d'une architecture dite 3-tiers : la vue est mise en oeuvre par des JSP, le contrôleur est mis en oeuvre par des servlets et des Javabeans. Différents mécanismes peuvent être utilisés pour accéder aux données.
L'utilisation du modèle MVC rend un peu plus compliqué le développement de l'application qui le met en oeuvre mais il permet une meilleure structuration de celle-ci.
Dans ce modèle, chaque requête est traitée par un contrôleur sous la forme d'une servlet. Celle-ci traite la requête, fait appel aux éléments du model si nécessaire et redirige la requête vers une JSP qui se charge de créer la réponse à l'utilisateur.
L'inconvénient est donc une multiplication du nombre de servlets nécessaires à l'application : l'implémentation de plusieurs servlets nécessite beaucoup de code à produire d'autant que chaque servlet doit être déclarée dans le fichier web.xml.
Le principal défaut du modèle MVC est le nombre de servlets à développer pour une application.
Pour simplifier les choses, le modèle MVC model 2 ou MVC2 propose de n'utiliser qu'une seule et unique servlet comme contrôleur. Cette servlet se charge d'assurer le workflow des traitements en fonction des requêtes http reçues.
Le modèle MVC 2 est donc une évolution du modèle 1 : une unique servlet fait office de contrôleur et gère toutes les requêtes à traiter en fonction d'un paramétrage généralement sous la forme d'un fichier au format XML.
Le modèle MVC II conserve les principes du modèle MVC, mais il divise le contrôleur en deux parties en imposant un point d'entrée unique à toute l'application (première partie du contrôleur) qui déterminera à chaque requête reçue les traitements applicatifs à invoquer dynamiquement (seconde partie du contrôleur).
Une application web implémentant le modèle MVC de type II utilise une servlet comme contrôleur traitant les requêtes. En fonction de celles-ci, elle appelle les traitements dédiés généralement encapsulés dans une classe.
Dans ce modèle, le cycle de vie d'une requête est le suivant :
Il existe deux grandes familles de framework web pour les applications J2EE : ceux reposant sur les requêtes et ceux reposant sur les composants.
Cette dernière famille est assez récente : elle repose aussi sur HTTP (donc sur les requêtes) mais propose de faciliter le développement et surtout de rendre plus riches les applications en utilisant des composants dont le rendu est généré par le serveur avec une gestion des événements. Ce type de framework va devenir la référence dans un futur proche et est proposé comme la nouvelle génération de framework pour le développement web.
En mars 2002, Tapestry a été le premier framework de ce type diffusé en open source. En Mars 2004, le JCP propose les Java Server Faces qui sont le standard de framework web intégré dans Java EE 5.
Les frameworks reposant sur le traitement de requêtes utilisent un cadre de développement exploitant les servlets et les JSP pour faciliter le traitement de certaines tâches répétitives (extraction des données de la requête, enchaînement des pages, utilisation de bibliothèques de tags spécifiques pour l'IHM, ...). Ces framework reposent généralement sur le modèle MVC2.
Exemple : Struts, WebWork, Spring MVC, ...
Les frameworks présentés dans cette section regroupent les principaux frameworks open source et les JSF. Les frameworks open source sont nombreux, notamment : Spring MVC, Struts , Tapestry, Turbine, VRaptor, Wicket, ...
Seuls les principaux sont rapidement présentés dans les sections suivantes. Certains font l'objet d'un chapitre dédié.
Struts est un projet du groupe Jakarta de la fondation Apache. La page officielle de Struts est à l'url : https://struts.apache.org/.
Struts est le framework open source le plus populaire : son utilisation est largement répandue.
Son architecture met en oeuvre le modèle MVC 2. Il utilise les servlets, les JSP, XML, les resourcesbundles (pour l'internationalisation) et des bibliothèques du projet Jakarta Commons.
Struts se concentre sur le contrôleur et la vue. Il ne propose rien concernant le modèle ce qui laisse le développeur libre pour mettre en oeuvre des Javabeans, des EJB ou toute autre solution pour la persistance des données.
La partie vue peut utiliser les tags proposés par Struts qui sont assez fournis mais qui nécessitent souvent l'ajout de bibliothèques supplémentaires pour gagner en productivité (exemple : Struts-Layout). Il est aussi possible d'utiliser ses propres tags et/ou d'utiliser la JSTL (Java Standard Tag Libraries).
Struts possède cependant quelques faiblesses : de conception assez anciennes, il est techniquement inférieur à d'autres frameworks notamment ceux reposant sur les composants.
Il est aussi légitime de s'interroger sur le futur de Struts, notamment avec l'arrivée des JSF qui vont devenir le standard de la plate-forme J2EE, et ce d'autant plus que le créateur de Struts participe activement aux spécifications des JSF par le JCP.
Les atouts de Struts sont :
| Avantages | Inconvénients |
Est quasiment un standard de fait |
Son avenir |
Nombreuses sources d'informations |
Peu d'évolutions |
Bibliothèques de tags HTML |
une architecture vieillissante |
Intégration dans les IDE |
Beaucoup de classes et de code à produire (partiellement automatisable avec des outils dédiés) |
Open source |
|
Struts est détaillé dans le chapitre «Struts».
Le framework web Spring MVC fait partie intégrante du framework Spring. Ce dernier propose une architecture complète pour le développement d'applications J2EE dont le module MVC assure le développement de la partie IHM pour les applications web. L'utilisation de ce module peut être remplacée par d'autres frameworks notamment Struts grâce à la facilité de Spring à s'interfacer avec ces produits.
Le succès de Spring repose principalement sur la facilité qu'il a à permettre de développer des applications d'entreprise sans EJB tout en proposant les mêmes fonctionnalités que ces derniers grâce notamment à l'utilisation du design pattern IoC et à la programmation orientée aspect.
Le page officielle des projets Spring est à l'url : https://spring.io/
Tapestry est un projet open source développé par la fondation Apache.
La page officielle de ce projet est à l'url : https://tapestry.apache.org.
L'intérêt pour le projet s'est accru depuis la diffusion des JSF car ils utilisent tous les deux les composants serveurs.
La partie vue n'utilise pas de JSP mais des fichiers HTML enrichis avec des tags particuliers.
Les JSF (Java Server Faces) constituent un framework de composants graphiques, hébergés côté serveur et utiles pour le développement d'applications Web. C'est un framework basé sur des spécifications du JCP. Il dispose à ce titre d'une implémentation de référence.
Les Java Server Faces sont développés par le JCP sous la JSR 127 pour la version 1.0, la JSR 252 pour la version 1.2 et la JSR 314 pour la version 3.0.
La page officielle du projet est à l'url : https://www.oracle.com/java/technologies/javaserverfaces.html
Les JSF sont construits sur un modèle de développement orienté événementiel à l'image de SWING. Il se compose d'un ensemble d'API servant, notamment,
Les valeurs ajoutées par ce framework sont :
Ces spécifications possèdent une implémentation de référence (RI) ainsi que des implémentations open source (MyFaces, ...) et commerciales (ADF Faces, ...).
| Avantages | Inconvénients |
Standard du JCP |
Maturité |
Utilisation de composants et de la gestion d'événements |
Manque de composants évolués (à développer ou à obtenir d'un tiers) |
Possibilité de créer ses propres composants |
Développement très orienté sur la vue (celle-ci contient la définition des validations et des méthodes à appeler pour les traitements) |
Intégration forte dans certains IDE (Sun Studio Creator, ...) pour permettre des développements de type RAD |
Peu de retour sur les performances (cycle de traitement des requêtes avec de nombreuses étapes) |
Possibilité d'utiliser plusieurs types de rendus grâce à des toolkits (seul HTML est proposé en standard dans l'implémentation de référence) |
|
De base, pas besoin d'hériter de classes ou d'implémenter d'interfaces dédiées : de simples beans suffisent |
|
Les JSF sont détaillées dans le chapitre «JSF (Java Server Faces)».
La version 2 du framework Struts est constituée d'une fusion des framework Struts et WebWork.
Strut 2 requiert Java 5, Servlet 2.4 et JSP 2.0.
La page officielle du projet est à l'url : https://struts.apache.org/2.x/
Le projet Struts Shale repose sur les JSF pour proposer de faciliter le développement d'applications web.
Ce projet est incompatible avec le framework Struts 1.x. Il a été abandonné en mai 2009.
La page officielle du projet est à l'url : https://shale.apache.org
Expresso était un framework open source développé par la société JCorporate.
C'était un framework pour le développement d'applications Web J2EE qui agrège de nombreux autres frameworks chacun dédié à une tâche particulière.
Il repose sur Struts depuis sa version 4.0.
Une des particularités de ce framework est de proposer un ensemble de fonctionnalités assez complètes :
La version 5.0 de ce framework est disponible depuis octobre 2002. La version 5.5, publiée en mai 2004 repose sur Struts 1.1. La version 5.6 est publiée en janvier 2005.
La page officielle de ce projet est à l'url : https://jena.apache.org
La page officielle du projet est à l'url https://turbine.apache.org/
La page officielle du projet est à l'url https://wicket.apache.org/
Les frameworks de mapping Objet/relationel sont détaillés dans le chapitre «La persistance des objets».
Le logging est important dans toutes les applications pour faciliter le débogage lors du développement et conserver une trace de l'exécution lors de l'exploitation en production.
Une API très répandue est celle développée par le projet open source Log4j du groupe Jakarta.
Concient de l'importance du logging, Sun a développé et intégré au JDK 1.4 une API dédiée. Cette API est plus simple à utiliser et elle offre moins de fonctionnalités que Log4j mais elle a l'avantage d'être fournie directement avec le JDK.
Face au dilemme du choix de l'utilisation de ces deux API, le groupe Jakarta a développé une API qui permet d'utiliser indifféremment l'une ou l'autre selon leur disponibilité.
L'utilisation de ces entités est détaillée dans le chapitre «Le logging».
Il existe aussi d'autres frameworks de logging dont l'utilisation est largement moins répandue.
|
|
