IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

 

Développons en Java   2.30  
Copyright (C) 1999-2022 Jean-Michel DOUDOUX    (date de publication : 15/06/2022)

[ Précédent ] [ Sommaire ] [ Suivant ] [Télécharger ]      [Accueil ]

 

107. Les frameworks

 

chapitre    1 0 7

 

Niveau : niveau 4 Supérieur 

 

Le développement en Java impose certaines contraintes :

  • nécessité de maitriser de nombreux concepts généraux (notamment celui de la POO, les design patterns, etc ...) et spécifiques aux plates-formes Java (standard, entreprise et mobile) selon les besoins
  • nécessité de maitriser de nombreuses API qui sont de bas niveau
  • quasi-absence d'outils de type RAD

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 :

 

107.1. La présentation des concepts

Le développement d'applications peut être facilité grâce à l'utilisation :

  • de la POO et des design patterns lors de la conception
  • de boîtes à outils : ce sont des classes qui proposent des utilitaires basiques
  • de frameworks

 

107.1.1. La définition d'un framework

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 :

  • un ensemble de classes généralement regroupées sous la forme de bibliothèques pour proposer des services plus ou moins sophistiqués
  • un cadre de conception reposant sur les design patterns pour proposer tout ou partie d'un squelette d'application
  • des recommandations sur la mise en oeuvre et des exemples d'utilisation
  • des normes de développement
  • des outils facilitant la mise en oeuvre

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 :

  • l'architecture de base de l'application
  • l'accès aux données
  • l'internationalisation
  • la journalisation des événements (logging)
  • la sécurité (authentification et gestion des rôles)
  • le paramétrage de l'application
  • ...

La mise en oeuvre d'un framework permet notamment :

  • de capitaliser le savoir-faire sans "réinventer la roue"
  • d'accroître la productivité des développeurs une fois le framework pris en main
  • d'homogénéiser les développements des applications en assurant la réutilisation de composants fiables
  • donc de faciliter la maintenance notamment évolutive des applications

Cependant, cette mise en oeuvre peut se heurter à certaines difficultés :

  • le temps de prise en main du framework par les développeurs peut être plus ou moins long en fonction de différents facteurs (complexité du framework, richesse de sa documentation, expérience des développeurs, ...)
  • les évolutions du framework qu'il faut répercuter dans les applications existantes

 

107.1.2. L'utilité de mettre en oeuvre des frameworks

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 :

  • adoption par la communauté
  • la qualité de la documentation
  • le support (commercial ou communautaire)
  • le support par les outils de développement

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.

 

107.1.3. Les différentes catégories de framework

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 :

  • logging
  • mapping O/R
  • automatisation des tests
  • ...

Ainsi, les frameworks peuvent être regroupés en plusieurs catégories :

  • Technique : propose des services techniques récurrents
  • Structurel : propose la mise en place d'une architecture applicative
  • Métier : propose des services fonctionnels
  • Tests : propose des services pour automatiser les tests unitaires

 

107.1.4. Les socles techniques

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 :

  • sélection des frameworks à mettre en oeuvre
  • sélection des outils à utiliser
  • définition de l'architecture applicative et de ses couches
  • création d'un projet "vide" par assemblage des frameworks et des classes de bases des différentes couches
  • validation par un prototype
  • définition de normes de développement
  • apprentissage du socle (plusieurs semaines de pratique sont nécessaires pour être généralement pleinement opérationnel)
  • rédaction de la documentation technique
  • ...

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.

 

107.2. Les frameworks pour les applications web

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 :

  • la nature du protocole http (basé sur un modèle simple de request/response sans état)
  • les nombreuses technologies à mettre en oeuvre (HTML, XHTML, CSS, JavaScript, ... ) ainsi que leurs différentes versions
  • le support de ces technologies par les différents navigateurs est particulièrement différent
  • HTML est un langage pauvre qui ne permet que le développement de formulaires assez rudimentaires

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 :

  • les API Servlet et JSP sont de bas niveau
  • le manque de modèles événementiels (cet argument explique le développement de la technologie JSF)

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.

 

107.3. L'architecture pour les applications web

 

107.3.1. Le modèle MVC

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 :

  • le Modèle représente les données de l'application  généralement stockées dans une base de données
  • la Vue correspond à l'IHM (Interface Homme Machine)
  • le Contrôleur assure les échanges entre la vue et le modèle notamment grâce à des composants métiers

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.

 

107.4. Le modèle MVC type 1

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.

 

107.5. Le modèle MVC de type 2

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 :

  1. Le client envoie une requête à l'application et cette requête est prise en charge par la servlet faisant office de contrôleur
  2. La servlet analyse la requête et appelle la classe dédiée contenant les traitements
  3. Cette classe exécute les traitements nécessaires en fonction de la requête, notamment, en faisant appel aux objets métiers
  4. En fonction du résultat, la servlet redirige la requête vers la page JSP
  5. La JSP génère la réponse qui est renvoyée au client

 

107.5.1. Les différents types de framework web

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

 

107.5.2. Des frameworks pour le développement web

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 MVCStruts , 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é.

 

107.5.2.1. Apache Struts

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  :

  • une bibliothèque de tags mature, robuste et complète.
  • l'introspection des objets relatifs aux formulaires
  • les formulaires de type DynaActionForm
  • la validation est extensible, elle peut être faite côté client ou côté serveur.
  • la gestion centralisée des exceptions
  • la décomposition de l'application en modules logiques reposant sur le modèle MVC 2
  • le support de l'internationalisation

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

 

107.5.2.2. Spring MVC

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/

 

107.5.2.3. Tapestry

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.

 

107.5.2.4. Java Server Faces

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,

  • à représenter les composants,
  • à gérer les états et les événements
  • à proposer des dispositifs de validation

Les valeurs ajoutées par ce framework sont :

  • spécifications standardisées
  • architecture de gestion des états des composants et des données correspondantes
  • extensible pour créer de nouveaux composants
  • support pour les différents types de clients (seul le renderer HTML est proposé dans l'implémentation de référence)
  • séparation entre le comportement et la présentation : les applications Web basées sur la technologie JSP permettent cette séparation mais elle reste très partielle. Une page JSP ne peut pas mapper plusieurs requêtes http sur un composant graphique ou gérer un élément graphique en tant qu'objet sans état côte serveur

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)».

 

107.5.2.5. Struts 2

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/

 

107.5.2.6. Struts Shale

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

 

107.5.2.7. Expresso

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 :

  • outils de mapping objet-relationnel pour la persistance des données
  • gestion d'un pool de connexions aux bases de données
  • workflow
  • identification et authentification pour la sécurité
  • ...

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.

 

107.5.2.8. Jena

La page officielle de ce projet est à l'url : https://jena.apache.org

 

107.5.2.9. Turbine

La page officielle du projet est à l'url https://turbine.apache.org/

 

107.5.2.10. Wicket

La page officielle du projet est à l'url https://wicket.apache.org/

 

107.6. Les frameworks de mapping Objet/Relationel

Les frameworks de mapping Objet/relationel sont détaillés dans le chapitre «La persistance des objets».

 

107.7. Les frameworks de logging

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.

 

 


[ Précédent ] [ Sommaire ] [ Suivant ] [Télécharger ]      [Accueil ]

78 commentaires Donner une note à l´article (5)

 

Copyright (C) 1999-2022 Jean-Michel DOUDOUX. Vous pouvez copier, redistribuer et/ou modifier ce document selon les termes de la Licence de Documentation Libre GNU, Version 1.1 ou toute autre version ultérieure publiée par la Free Software Foundation; les Sections Invariantes étant constitués du chapitre Préambule, aucun Texte de Première de Couverture, et aucun Texte de Quatrième de Couverture. Une copie de la licence est incluse dans la section GNU FreeDocumentation Licence. La version la plus récente de cette licence est disponible à l'adresse : GNU Free Documentation Licence.