20/05/2005

Comparatif JSF/Struts

L’atout de Struts étant :

  • une bibliothèque de tags mature, robuste et complète.
  • Les formulaires de type DynaActionForm
  • La validation est extensible, elle peut être faite côté client ou côté serveur.
  • Gestion centralisée des exceptions
  • Décomposition de l’application en modules logiques
  • Partage de la session entre les différents modules
  • Possibilité d’intégration des stratégies de sécurité
  • Support de l’internationalisation
  • Introspection des objets relatifs aux formulaires

JSF est une spécification permettant de développer des interfaces graphiques améliorées pour des applications Web basées sur la plate-forme J2EE. Les JSF utilisent un modèle Orienté événement. Elle propose dans son implémentation des composants graphiques réutilisables capables de gérer les états et les événements. Les JSF proposent aussi une librairie de balises à insérer dans des pages JSP.

Cette section présente un comparatif entre les frameworks Struts et JSF. Ce comparatif est complémentaire aux retours sur le Benchmark des frameworks Web.
Struts JSF Commentaires
Maturité ++ -/+
  • Struts bénéficie d’un retour d’expérience positif de la part de ses utilisateurs et des entreprises qui maintiennent des applications en production. L’exemple le plus parlant concerne la console d’administration de WebSphere 5.
Flexibilité du contrôleur + ++
  • JSF peut avoir plusieurs gestionnaires d’événements au sein d’une seule page tandis que Struts ne peut déclencher qu’un seul événement par requête utilisateur.
Navigation + ++
  • JSF propose un dispositif de navigation plus flexible que celui de Struts en le découplant du code applicatif.
Extensibilité + ++
  • Struts est extensible via la classe RequestProcessor qui implémente les appels aux méthodes durant le cycle de vie d’une requête.
  • JSF dispose d’une fonctionnalité similaire, en plus il a l’avantage de découpler la phase de rendement du contrôleur, ce qui permet de un développement flexible de toolkits de rendu.
Développement + ++/-
  • Les JSFs facilite la combinaison des GUIs complexes au sein d’un seul composant.
  • JSF fait partie de la J2EE et bénéficie d’une spécification standard.
  • JSF est plus adaptée au Développement de type RAD.
  • Le développement basé sur JSF ne nécessite pas d’étendre des classes ou implémenter des interfaces spécifiques.
  • La configuration d’une application Struts est plus laborieuse qu’une application JSF.
  • Le module de validation de Struts est plus efficace et robuste que celui des JSFs.
  • Le module de validation de Struts peut se faire cote client, ce n’est pas le cas pour les JSFs.
Intégration + ++
  • JSF n’est pas limité à HTML et http mais aussi à d’autres technologies et protocoles

08:10 Publié dans Frameworks | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Architectes NTIC

18/05/2005

JSF-Struts Etat de l'Art

Les tentatives de fusion entre les philosophies de la version actuelle de Struts et celle des JSF ont échoué. Jakarta a récemment déclaré que deux versions de Struts vont cohabiter : Struts Classic (versions 1.x) et Struts Shale (version 2.x).

La version classique de Struts restera maintenue si les contributeurs acceptent de la faire vivre.

Struts Shale est une réécriture totale de Struts. Il n’a pas pour objectif d’implémenter les spécifications JSF, mais de fournir des briques packagées sous forme de Framework et qui englobent une implémentation des JSF comme MyFaces.

JSF est plutôt focalisé sur le tiers Vue, alors que Shale (ainsi que Struts 1.x) est plus concerné par le tiers Contrôleur.

Il est important à noter que l’équipe Apache Struts Team encourage le choix des JavaServer Faces pour les développements des UI.

Les spécifications JSF sont préférées au framework Struts.

08:10 Publié dans Frameworks | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Architectes NTIC

13/05/2005

Comparatif Framework WEB PART IV

La testabilité

Framework Commentaire Testable
Struts Utiliser StrutsTestCase adapté à la philosophie Struts.
Spring Possibilité d’utiliser les mocks pour les tests (SpringMock, Jmock, EasyMock)
WebWork Possibilité d’utiliser les mocks pour les tests (SpringMock, Jmock, EasyMock)
Tapestry Impossible à tester.
JSF Assez aisé à tester.

05:00 Publié dans Frameworks | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Architectes NTIC

09/05/2005

Comparatif Framework WEB PART III

Respect des Standards

Framework Commentaire Respecte les standards
Struts Se base sur les spécifications JSP/Servlet.
Spring Se base sur les spécifications J2EE.
WebWork Se base sur les spécifications JSP/Servlet.
Tapestry Utilise des scripts non-standardisés.
JSF JSF est un standard J2EE.

08:50 Publié dans Frameworks | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Architectes NTIC

07/05/2005

Comparatif Framework WEB PART II

Inconvénients et Avantages des frameworks

Framework Avantages Inconvénients
Struts
  • Framework très utilisé et mature.
  • Documentation et guides très abondants
  • Une libraire de tags très riche.
  • Plusieurs IDE proposent des plug-ins qui facilitent le développement.
  • Difficulté de faire des tests unitaires, il n’est possible de faire que des tests d’intégration.
  • Gestion des formulaires.
  • Systèmes de validation non-standardisés.
Spring
  • Basé sur le pattern IoC, possibilité d’intégrer des services en plug-and-play.
  • S’intègre avec plusieurs technologies coté Vue.
  • Problème de flexibilité,
  • Absence de librairie de tags utilitaire.
WebWork
  • Architecture simple, facile à étendre
  • Librairie de tags facile à personnaliser.
  • Validation côté client immature.
  • Documentation pauvre et manque d’exemple et de retour d’expérience.
Tapestry
  • Très productif une fois maîtrisé
  • Les templates sont très accessibles aux graphistes
  • Supporté par une communauté d’expert.
  • Documentation très conceptuelle.
  • Manque d’exemples.
JSF
  • Standard J2EE.
  • Développement rapide et facile.
  • Framework de navigation très riche.
  • Framework évènementiel.
  • Architecture extensible de générateur de composants
  • Spécifications standardisées
  • Support pour les différents types de clients.
  • Séparation à grain fin 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 de gérer un élément graphique en tant qu’objet sans état cote serveur.
  • Architecture de gestion des états des composants et des données correspondantes.
  • La technologie n’a pas encore fait ses preuves.
  • Mélange des tags JSF et JSP dans les pages JSP.
  • Exécute des POST HTTP pour tout.
  • Plusieurs sources d’implémentation.
  • Pas de possibilité d’accès au contrôleur.
  • Pauvreté de la mise en forme à cause de l’indisponibilité de fonctionnalités comme les Tiles de Struts.

14:50 Publié dans Frameworks | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Architectes NTIC

04/05/2005

Comparatif Framework WEB PART I

Les frameworks utilisés pour le comparatif

Les Frameworks choisis pour le benchmark sont les suivants :

Framework Description
Struts Un autre framework respectant le paradigme MVC.
Spring Spring est un framework permettant de développer des applications J2EE. Il est basé sur les concepts IoC, AOP.
WebWork Ce framework utilise le concept du Pull Hierarchical Model View Controller.
Tapestry Un autre framework respectant le paradigme MVC.
JSF Les spécifications JSF fournissent un modèle de développement totalement événementiel et orienté composant des d'interfaces graphiques web.

Ci-dessous les versions utilisées pour effectuer le benchMark :

Nom Adresse de téléchargement Version
Struts Http://jakarta.apache.org/struts/ 1.2.4
Spring Http://www.springframework.org/ ... 1.0

09:40 Publié dans Frameworks | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Architectes NTIC

29/04/2005

Le résulat du comparatif des frameworks de persistance

Le benchmark a fait ressortir trois frameworks de persistance dont les fonctionnalités sont intéressantes :

  • Hibernate
  • JPOX
  • OJB

Ci-dessous un tableau récapitulatif des avantages et inconvénients

FRAMEWORK INCONVENIENTS AVANTAGES
Hibernate
  • Ne se base pas sur les spécifications et standards JDO ou ODMG
  • Possibilité de perte de vitesse après l’acceptation des spécifications JDO 2.0
  • Nécessite un module pour la connectivité aux bases Oracle
  • Propose une API performante et robuste
  • Est mature et dispose d’un support fiable et d’une documentation abondante
  • Supporte la gestion des transactions
  • S’intègre facilement à Eclipse et Spring
  • Appropriation rapide
JPOX
  • Framework en version alpha
  • Documentation insuffisante
  • Une implémentation de référence des JSR JDO 1.0 et 2.0
  • Projet promu par SUN
  • En gain de crédibilité
OJB
  • Implémentation des spécifications JDO 1.0
  • Pas de RoadMap pour l'Implémentation des spécifications JDO 2.0

JPOX reste plus complet qu’OJB en terme de gestion transactionnelle et de conformité aux dernières spécifications et standards JDO.

JPOX dispose des fonctionnalités suivantes :

  • Identité niveau application ou datastore,
  • Generateurs d’identités via plusieurs algorithmes,
  • Attach/detach des instances,
  • Transactions optimistes et pessimistes,
  • Environnement multi-threadé,
  • Intégration à la plate-forme J2EE
  • Gestion du cycle de vie des objets
  • Cache
  • Enhancement (Enrichissement) des objets.
  • Intégration parfaite avec Spring.

Le framework de persistance le plus intéréssant reste : JPOX.

08:35 Publié dans Frameworks | Lien permanent | Commentaires (1) | Envoyer cette note | Tags : Architectes NTIC

27/04/2005

Comparatif framework de persistance

Ci-dessous les frameworks de persistance choisis pour le benchmark : On a choisi d’effectuer un comparatif entre des frameworks JDO (Frameworks standards) et Hibernate (Framework non-standard).

Nom Description Libre
Hibernate TODO 1
LiDO TODO 0
Castor Castor propose une solution pour gérer la persistance et les transactions. 1
OJB OJB est une implémentation des spécifications JDO 1.0 et ODMG 3.0 1
JPOX JPOX est une implémentation de la spécification JDO 2.0. Ce projet est promu par SUN comme le projet de référence de JDO 2.0. 1

Ci-dessous les versions utilisées pour ce BenchMark.

Nom Adresse de téléchargement Version
Hibernate http://www.hibernate.org 3.0
LiDO http://www.xcalia.com/products/lido.jsp 3.0
Castor http://castor.exolab.org 0.9.6
OJB http://db.apache.org/ojb/ 1.0.1
JPOX http://www.jpox.org 1.1

Ci-dessous le tableau du comparatif :

Hibernate Lido Ojb Castor Jpox Commentaire
Propose une GUI pour le mapping + + + - + L’éditeur de mapping d’Hibernate s’intègre à la plate-forme Eclipse.
Persistance des classes arbitraires (Pas d’obligation de classe mère ou interface spécifiques) + + + + +

Il faut implémenter Timestampable pour lecture/écriture dans des transactions séparées.
Nécessite une requête SQL manuellement. - - - - -  
Indépendant des RDBMS. + + + + + Hibernate et Lido ont une distribution spéciale pour Oracle.
Supporte les EJBs + + + - + Hibernate supporte les beans session de type stateful/stateless session et les benas entité BMP, JTA, JNDI, JMX intégration et JCA.
Supporte les relations entre objets + + + + +  
Supporte la clause GROUP BY + + + - +  
Supporte les fonctions count, avg + - + - +  
Propose un générateur d’objets à partir de fichier de mapping + + + - + Hibernate reste complet à ce niveau.
Supporte l’aggregation du mapping. + - + + + Castor reste très limité.
Supporte les clefs primaires composites + + + + + Hibernate supporte les clefs primaires multiples en tant qu’objet ou propriétés d’objet.
Supporte les associations many to many et one to many + + + + +  
Supporte les collections typées. + + + + +
Supporte les associations one to one + + + + +  
Supporte le polymorphisme + + + - + Hibernate supporte trois stratégies de mapping: table-per-hierarchy, table-per-concrete-class, table-per-subclass
Supporte l’héritage + + + + +  
Génération de jointures automatique + + + + + Hibernate supporte les jointures externes de type ANSI et Oracle
API compatible SUN JDO - + + - +  
Supporte les serveurs multiples + - + - +
Nécessite une génération de code ou un enhancement manuel. - + - - -  
Utilise la réflexion. - - - + +
Supporte le cache des résultats. + + + + +  
Supporte le mapping d’une classe sur plusieurs tables + - + + +
Supporte le mapping de plusieurs classes sur une table + + + - +  
Supporte la persistance des propriétés privées + - + - +  
Supporte la persistance des propriétés via des accesseurs et mutateurs + - + + +
Supporte les méthodes de création, suppression, modification - - - + +  
Supporte l’accès aux systèmes de stockage via JNDI + - - - +
Supporte les pools de connections + - - - +  
Supporte la génération des séquences pour les identités des tables + + + + +
Supporte l’état déconnecté + - - - +  
S’intègre avec Spring + - - + +  
Total / 32 27 19 23 17 30 Le benchmark tourne en faveur du framework JPOX.

08:20 Publié dans Frameworks | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Architectes NTIC

21/04/2005

Le cycle de vie des JSFs

Le contrôleur principal FacesServlet crée un objet FacesContext qui contient les informations nécessaires à l’exécution d’une requête utilisateur. Plus précisément, l’objet FacesContext contient à la fois les objets ServletContext, ServletRequest et ServletResponse qui sont passés en paramètres de la méthode service de FacesContext par le conteneur Web.


  1. Reconstitution de l’arbre de contrôle : Une page JSP de type JSF est représentée par un arbre de composants. Chaque composant dispose d’un identifiant unique. Cet arbre est sauvegardé au sein de l’objet FacesContext afin d’être traité dans les phases suivantes.
  2. Application des valeurs de la requête : Les valeurs locales de chaque composant de l’arbre sont mises à jour à partir de la requête courante. Ces valeurs peuvent provenir des paramètres de requête, d’attributs de requête, de cookies, etc
  3. Validation des valeurs appliquées : Apres la phase de mise à jour des valeurs l’objet LifeCycle procède à la validation de ces dernières. Tout composant qui nécessite une validation doit implémenter la logique de cette dernière. Lorsqu’une valeur stockée est invalide, l’application JSF ajoute un message d’erreur, affichage lors de la phase du rendu.
  4. Mise à jour des valeurs du modèle objet : Cette phase n’est traitée que si tous les composants sont valides. Les valeurs des composants sont affectées aux valeurs du modèle d’objet. Ceci nécessite une conversion des données, si l’objet LifeCycle ne dispose pas du mécanisme de conversion nécessaire en fonction du type de la propriété du modèle objet.
  5. Appel d’une application : Cette phase consiste au traitement des événements au niveau des applications. Le traitement est effectué via l’interface ApplicationHandler, laquelle définit la page à atteindre lorsqu’un événement sollicitant l’application se produit.
  6. Affichage de la réponse : Cette phase correspond à la génération de la réponse à afficher.

07:50 Publié dans Frameworks | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Architectes NTIC

20/04/2005

Adoptons les JSFs PART I

Historique


Les dispositifs de la plate-forme J2EE les plus utilisés concernent le développement des applications Web. Ce type de développement est considéré comme le point d’entrée principal à la plate-forme J2EE.

Plusieurs spécifications comme : Servlet, JSP, Portlet permettent de définir une architecture flexible et robuste des applications Web.

Il se trouve que le développement de composants de présentation riches et sophistiqués est difficile à concevoir et à implémenter. Ceci est dû :

  • à la nature du protocole http (basé sur un modèle simple de request/response)
  • à la prolifération des dialectes du langage HTML
  • HTML est un langage pauvre, il réduit le développement à des formulaires rudimentaires,
  • au manque de modèle événementiels au sein de la plate-forme J2EE


Il existe donc un réel besoin d’un framework standard qui permette de gérer à la fois le modèle événementiel et proposer des toolkits de génération de composants graphiques riches et adaptables aux différents dialectes issus du langage HTML.

JSF


Les JSF (Java Server Faces) constituent un framework de composants graphiques hébergés côté serveur utiles pour le développement d’applications Web. C’est un framework basé sur un standard et une implémentation de référence.

Les JSFs sont construits sur un modèle de développement orienté événementiel à l’exemple de SWING. Il se compose d’un ensemble d’API servant, notamment,

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

Le but principal des JSFs c’est de proposer une implémentation de référence et un standard pouvant être intégré sans difficulté au niveau des différents IDE du marché.

JSF peut être considéré comme un autre framework MVC. Les valeurs ajoutées par ce framework sont :

  • Architecture extensible de générateur de composants
  • Spécifications standardisées
  • Support pour les différents types de clients.
  • Séparation à grain fin 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 de gérer un élément graphique en tant qu’objet sans état cote serveur.
  • Architecture de gestion des états des composants et des données correspondantes.

08:10 Publié dans Frameworks | Lien permanent | Commentaires (1) | Envoyer cette note | Tags : Architectes NTIC

Toutes les notes