Framework Web Java – Synthèse

Au cours des différents articles (Frameworks embarqués, Qu’est-ce que le JavaEE ? I, II et III) nous avons présenté de manière plus ou moins succinte de nombreux frameworks web basés sur le langages Java. Le nombre de frameworks existant était trop impressionnant pour que ceux-ci soient listés intégralement et de manière exhaustive dans nos articles, cependant nous avons tenté de décrire en priorité les frameworks les plus connus en se basant sur des sondages de développeurs afin de laisser de côté les frameworks les moins répandus.

Dans l’article “Comparatif des frameworks web Java”, nous avons comparé les frameworks présentés dans les articles précédents sur différents critères (maturité, open source, MVC, composants ou requête, servlets, interprétation directe du Java, templates, compilateur Java vers Javascript, facilité de prise en main / légèreté / simplicité), ceci dans un but de pouvoir déterminer dans une situation donnée, lequel de ces frameworks choisir.

Et c’est ce qui a été réalisé dans le dernier article ”Framework Web Java – Lequel choisir ?” où nous avons sélectionné plusieurs critères permettant de décrire un projet (temps disponible / échéance / coût, qualité / flexibilité du code, complexité, sécurité, durée d’utilisation / maintenance) et nous avons analysé quels frameworks devaient être choisi en préférence si l’un de ces critères était prioritaire pour le projet).

Framework Web Java – Lequel choisir ?

Dans ce dernier article nous allons comme prévu vous donner le ou les frameworks à utiliser selon le projet à réaliser. Dans ce but, nous allons premièrement lister les critères (ou facteurs de différenciation) d’un projet.

Tout d’abord, certains facteurs comme les compétences déjà présentes dans l’équipe, si le projet est dans un cadre scolaire, etc. pourraient être pris en compte mais se révèlent être des cas particuliers. En effet si l’équipe est compétente sur un framework alors il est plus judicieux d’utiliser ce dernier (ce qui permet au projet de gagner du temps de formation, et à l’équipe de gagner encore plus en expertise) et si le projet est réalisé dans un cadre scolaire alors les paramètres se retrouvent radicalement modifiés et il peut se révéler formateur et valorisant de prendre beaucoup de temps à apprendre à utiliser un framework plus complexe.

Dans les mises en situation suivante nous considérerons donc un projet a réaliser en entreprise avec les problématiques économique associées et nous ne prendrons pas en compte les compétences déjà acquises de l’équipe.

Voici alors la liste des critères retenu avec leurs solutions/frameworks associés :

    • Temps disponible / Échéance / Coût

Si le coût est prioritaire, que l’entreprise en difficulté ou que le projet a été mal négocié, il est alors préférable de réaliser rapidement le projet en mettant de côté la flexibilité du code et d’autres facteurs.
Et d’autres facteurs font que l’échéance du projet est courte ou que peu de temps est disponible pour développer le produit, il est alors de bon sens d’utiliser un framework facile à utiliser comme Stripes ou ZK, ou simple mais un peu plus complexe comme Echo3, GWT, Jena, Play, Tapestry ou Wicket.

    • Qualité / Flexibilité du code

Afin d’améliorer la qualité des produits, il est nécessaire d’augmenter la visibilité de l’étape des tests de validation et donc d’écrire les tests unitaires nécessaires à la détection des anomalies.
De nombreux frameworks Java mettent en avant la facilité de mise en oeuvre de tests : JUnit , TestNG.

Le principe de JUnit est d’écrire des tests portant chacun sur une fonctionnalité précise de l’application. De plus les tests doivent être écris en amont : le principe du morceau de code et le test permettant de dire si tout s’est déroulé correctement doivent être établis avant d’écrire celui-ci. Ceci permet de développer efficacement, en mettant en avant les fonctionnalités de l’application.
Réaliser des tests unitaires avec JUnit c’est donc développer en ayant une plus grande chance de satisfaire un objectif dans un but d’amélioration générale de la qualité du logiciel.

Heureusement pour les développeurs mais malheureusement pour notre comparaison, tous les frameworks permettent d’utiliser JUnit donc ce point n’est pas réellement un facteur de différenciation.

    • Complexité

Si la taille et/ou la complexité du projet est un facteur critique, il est conseillé d’utiliser un framework permettant de décomposer l’application en composants plus simples et se basant sur l’architecture MVC qui permet de structurer l’application en fonction de la tâche à accomplir.

De nombreux frameworks utilisent MVC : JSP, JBoss, Spring Framework, Play, Stripes et ZK mais le meilleur, dans le cadre d’un projet complexe, reste le framework Struts car en plus de possèder des bibliothèques puissantes de balises, celui-ci permet de :
- Développer plus rapidement.
- Écrire le minimum de code répétitif
- Résoudre de nombreux problèmes de conception.

    • Sécurité

Pour certains projets de développement informatique comme ceux manipulant des données sensibles, la mise en œuvre de règles de sécurité avancées est un point essentiel.
Pour cette raison il existe des frameworks qui aident les développeurs à construire leurs applications en sécurisant les données de leurs clients comme GWT et Spring Security.

Ces deux frameworks assurent la sécurité de l’application en offrant un mécanisme de sécurisation sur 3 points essentiels :

      1. Authentification

Celle-ci peut être réalisée de plusieurs façons et la plus courante consiste à utiliser un formulaire HTML afin de collecter un identifiant accompagné d’un mot de passe.
Dans le cas d’une application dont la couche de présentation est écrite en GWT, on peut écrire le formulaire d’authentification avec GWT ou bien le séparer sur une page dédiée.

      1. Validation des droits de l’utilisateur

Spring Security propose deux méthodes pour contrôler les droits.
- L’application d’un filtre sur l’URL (insuffisant sur des appels de type RPC)
- Une sécurisation des services par instrumentation du code qui permet quant à lui de répondre à ce problème “d’obfuscation” de l’action demandée.

      1. Mécanisme de déconnexion ou “remember-me”

Spring Security propose un filtre simple pour répondre à ce besoin : il suffit d’appeler une URL particulière pour détruire le contexte de sécurité. Cela fonctionne très bien avec une authentification par formulaire ou par cookie (remember me). Par contre, une authentification de type BASIC sera automatiquement récréée à la prochaine requête et seule une fermeture du navigateur, en plus de ce mécanisme, peut avoir raison de l’authentification (ceci est dû à cause du potentiel cookie du remember me).
Afin de supporter cette fonction de déconnexion, il convient donc de créer un composant GWT dont la responsabilité est la création d’une requête http pointant sur cette URL de déconnexion.

    • Durée d’utilisation / Maintenance

Si le produit doit être utilisé longtemps et, il est alors utile de faciliter la maintenance du produit et d’avoir un framework très structuré avec une architecture classique comme MVC. De plus il est aussi bon que le logiciel soit mature et ne va pas radicalement être modifié, ce qui nous laisse Struts, JSP, JBoss, Spring Framework, Stripes et ZK.

En recoupant suivant les critères d’un projet et en définissant clairement les critères prioritaires, on peut en conclure le framework à utiliser.

Nous avons bien conscience que le choix du framework à utiliser est un problème très complexe qui est réalisé par des architectes expérimentés et que nous ne pouvons que survoler le problème. Cependant nous espérons apporter un peu de lumière sur ce problème épineux en l’approchant de façon simplifiée.

Voilà c’était le dernier article. Nous espérons que vous avez apprécié les informations partagées sur les frameworks Web Java.

Toutefois il ne faut oublier que des frameworks Web existent dans d’autres langages comme Symfony2 avec PHP ou Django avec Python et Ruby on Rails avec Ruby et dans certaines situation, ces derniers peuvent se révéler plus efficaces que certains frameworks Java. Toutefois ceci n’entre pas dans le cadre de ce projet de Veille.

Pour terminer voici une petite ouverture sur un logiciel qui n’est pas vraiment un framework web Java et qui n’entre donc pas réellement dans le cadre du projet de veille mais qui permet de réaliser (entre autres) des applications web avec Java : Mule ESB. En réalité ce logiciel est plus complexe qu’un simple framework web Java. C’est un ESB (Entreprise Service Bus) qui permet de connecter très aisément des applications entre elles. Il se base sur Eclipse, s’utilise avec Java et peut se révéler très utile dès lors que plusieurs applications, webservices ou autres doivent être reliés dans une même application.

Bibliographie :
http://junit.sourceforge.net/javadoc/
http://www-igm.univ-mlv.fr/~dr/XPOSE2003/JUnit_tour/
http://www.mulesoft.org/what-mule-esb
http://ippon.developpez.com/tutoriels/java/gwt-spring-security/
http://jlafosse.developpez.com/livres/java/struts2/presentation/

Comparatif des frameworks web Java (1ère partie)

Nous allons maintenant comparer les différents frameworks que nous avons présenté au cours des articles précédents.

Dans cette première partie nous allons comparer, sous la forme d’un tableau, les frameworks sur ces différents critères :

  • Date de création
  • Maturité
  • Open Source
  • MVC
  • Composants ou Requête
  • Interprétation directe du Java
  • Templates
  • Compilateur Java vers Javascript
  • Facilité de prise en main / Légèreté / Simplicité

Et dans une seconde partie (prochain article) nous donnerons une solution adaptée à plusieurs situations requérant chacune l’emploi d’un framework Web Java et nous détaillerons les avantages de nos solutions par rapport à d’autres choix possibles.

Tout d’abord, quelques remarques :

  • Certains frameworks sont obsolètes et ne seront pas détaillés car ils n’entrent pas dans la comparaison
  • Les réponses critère de “facilité de prise en main” sont vagues et subjective mais nous avons voulu donner un ordre d’idée de la complexité de l’application. En effet Apache Struts est bien plus complexe à utiliser que Play mais ce ne représente pas nécessairement un désavantage (dépend du point de vue). On retrouve de façon logique que ce sont les frameworks à composants, développés dans un but d’être plus simple que ceux à requêtes, sont moins difficiles à utiliser que ces derniers mais moins enclins aux situations inhabituelles.
  • Par maturité nous entendons que le framework est stable et possède une documentation complète.
  • Le comparatif ne se veut pas exhaustif. Par exemple de nombreux templates peuvent être couplés aux différents frameworks mais nous voulions juste donner une vue d’ensemble.
  • Plusieurs critères n’ont pas été abordé car ils sont équivalents pour tous les frameworks :
    • Pas de colonne test car tous intègrent JUnit de base et peuvent facilement intégrer Selenium ou d’autres.
    • Pas de colonne ORM (Mapping Objet-Relationnel) car tous les frameworks ou presque intègrent de base Hibernate et/ou JPA et dans le cas contraire quelques manipulations suffisent pour les y intégrer.
  • Enfin d’autres critères n’ont pas été abordé par manque d’informations :
    • Nous aurions pu parler de l’activité des communautés de chacun de ces frameworks mais pour obtenir un avis objectif et pertinent il serait nécessaire d’utiliser tous les frameworks présenté ce que nous n’avons pas pu réaliser.
    • Respect du protocole REST
    • Gestion des routes
    • Conservation de l’état entre les requêtes (Play, Tapestry et ZK sont stateless contrairement aux frameworks Wicket et GWT qui sont stateful mais ces informations sont diffciles à trouver sans utiliser ces frameworks).

Voici donc le tableau comparatif :

De plus voici les liens vers les sites officiels de chacun de ces frameworks :

Apache Struts : http://struts.apache.org/
Echo3 : http://echo.nextapp.com/site/echo3
Expresso : http://www.jcorporate.com/html/products/expresso.html
GWT : http://www.gwtproject.org/
Java Server Faces : https://javaserverfaces.java.net/
JBoss Seam : http://www.jboss.org/overview/
Jena : http://jena.apache.org/
Play : http://www.playframework.com/
Spring Framework : http://projects.spring.io/spring-framework/
Stripes : http://www.stripesframework.org/display/stripes/Home
Struts Shale / Attic : http://attic.apache.org/
Tapestry : http://tapestry.apache.org/
Turbines : http://turbine.apache.org/
Webwork : Fermé
Wicket : https://wicket.apache.org/
ZK : http://www.zkoss.org/

Bibliographie :
http://www.jcorporate.com/html/products/expresso.html
http://www.javacorporate.com/expresso/doc/edg/Expresso_fr.pdf
http://www.itworld.com/development/69162/apache-shale-web-framework-project-retired
http://pathfindersoftware.com/2006/06/an_interview_wi-2/
http://fr.openclassrooms.com/informatique/cours/creez-votre-application-web-avec-java-ee/framework-mvc-base-sur-les-composants
https://wicket.apache.org/
http://echo.nextapp.com/site/
http://www.stripesframework.org/display/stripes/Home
http://tapestry.apache.org/tapestry3/doc/DevelopersGuide/engine.stateless.html
http://projects.spring.io/spring-framework/
http://turbine.apache.org/turbine-concepts.html
http://www.seamframework.org/

Qu’est-ce que le JavaEE ? (3ème et dernière partie)

Cet article va tout d’abord et comme prévu détaillé les frameworks Expresso, Wicket et Jena. De plus il présentera le frameworks JBoss Seam.

Nous sommes conscient que certains frameworks ont été laissé de côté comme FormEngine, ItsNat, Vaadin et bien d’autres mais nous avons préféré nous concentrer sur les frameworks les plus connus.

Expresso est un framework et une bibliothèque de composants qui aide au développement d’applications web riches en fonctionnalités et est adapté à celles pour lesquelles la base de donnée est la partie essentielle de l’application.

- Architecture MVC :
Les composants sont identifiés afin de créer des objets contrôleurs et l’utilisateur interagit avec ces composants utilisables par n’importe quel type de clients (servlets, pages jsp, applications, etc.).
Les servlets (interaction avec la base de donnée) et les pages jsp sont créés très rapidement.

- Services fournis :
La configuration de l’application : un objet de la classe “Shema” est utilisé afin de configurer automatiquement l’application et ainsi Expresso crée toutes les tables de la base de données demandées par les objets de type base de donnée.
Entrée de sécurité fournie pour tous les objets contrôleur de l’application.

- Quelques mots sur les connexions aux bases de données :
- Chaque utilisateur peut travailler sur des bases différentes avec des éditeurs différents. En effet une unique classe DBConnectionPool permet l’accès à de nombreux pools de connexion différents.
- Le pool de connexion permet de spécifier des options spéciales “base de données” en tant que propriétés.

Wicket est un logiciel open source orienté composants de la fondation Apache. Ce framework est relativement simple d’utilisation et ne nécessite pas de code HTML spécifique ou de fichier de configuration XML comme d’autres frameworks. En effet il repose sur une API semblable à Swing et utilise de simple objets POJOs et des pages html. Chaque page web est vu comme un ensemble de composants que l’on pourra réutiliser ailleurs.

- Quelques avantages:

Wicket gère la notion du composition, ce qui signifie qu’il simplifie l’ajout d’un composant ou d’une mise en forme conditionnelle. Ceci permet de créer un template de présentation sans ajouter des bibliothèques.

Ce framework ne génère pas de code HTML à la place du développeur mais permet, grâce à sa gestion des composants et de leur imbrication, de forcer le développeur à écrire des pages HTML valides. En effet sans cela, ce dernier ne pourrait faire le lien entre la logique Java de la page et les composants HTML qui y sont rattachés.

De plus Wicket intègre de façon native Ajax, ce qui facilite beaucoup le travail du développeur .

- Les inconvénients:

Les composants de Wicket restent assez basiques et l’application à développer se révèle hors norme, il se trouve alors nécessaire de créer de nouveaux composants (une nouvelle bibliothèque), ce qui peut prendre du temps.

Ainsi le développeur peut rencontrer des problématiques telles que la réutilisabilité de certains composants et l’homogénéité de la solution choisie.

Jena est un framework créé dans le but de développer des applications du web sémantique. Celui-ci interroge les sources de données citées dans la mémoire (points d’accès SPARQL, interfaces Linked Data, etc.) et fournit un ensemble d’outils et de librairies pour faciliter le travail avec RDF (Ressource Description Framework), RDFS (RFS Shema) et OWL (Web Ontology Langage).

Il utilise notamment les librairies de ARQ et un moteur d’interrogation du Web sémantique capable de traiter des requêtes SPARQL.

JBoss Seam est un serveur d’application relativement récent (2005) pour J2EE 5 qui se donne pour but d’aggréger ce qu’il y a de meilleur dans cette dernière version de Java pour obtenir les meilleures performances possibles.
Il se distingue par une volonté de simplicité par rapport à des concurrents et ne définit qu’un seul type de composant qui pourra faire partie sans distinction de la couche présentation ou de la couche métier.
Ce framework mixe et améliore (par exemple en limitant au minimum le besoin de configuration de fichiers xml au profit d’annotations plus simples et claires) les qualités de JSF pour la présentation et de EJB 3.0 pour la partie métier, intègre AJAX afin d’éviter à avoir à mettre les mains dans le Javascript.
Il dispose aussi de modules de tests plus poussés que du JUnit classique et qui permettent de simuler plus facilement un utilisateur en ayant une vue d’ensemble de tous les composants.

Bibliographie :
http://www.jcorporate.com/html/products/expresso.html
http://www.javacorporate.com/expresso/doc/edg/Expresso_fr.pdf
http://fr.wikipedia.org/wiki/Apache_Wicket
http://fr.clever-age.com/veille/blog/du-html-du-java-et-rien-d-autre-presentation-de-wicket.html
http://jena.sourceforge.net/documentation.html
http://code.ulb.ac.be/dbfiles/Gew2012mastersthesis.pdf
http://docs.jboss.org/seam/snapshot/fr-FR/html/Book-Preface.html

Remarque :
Un détail a été oublié dans les articles précédents : la date de consultation des pages web de la bibliographie. Nous tenions à préciser que ces pages ont été parcouru dans les deux semaines précédents chaque publication.

Qu’est-ce que le JavaEE ? (2ème partie)

Cet article va continuer la présentation du JavaEE mais ne couvrira pas le reste des frameworks à décrire comme convenu dans la première partie de “Qu’est-ce que le JavaEE ?”.
Il va en effet décrire les frameworks Tapestry, ZK, Struts Shale, Jena, Echo 2 et 3 et GWT tandis que Expresso et Wicket seront détaillés prochainement.

Tout comme Java Server Face, Tapestry est un framework basé sur les composants et sur un modèle MVC. Ses principes sont d’être d’une grande simplicité d’utilisation et de mettre en avant des conventions pour éviter des lourdeurs de configuration existantes dans d’autres framework.
Ce principe de conventions se traduit par des patrons de développement clairs et précis.
Ainsi les vues d’une application Tapestry sont proprement cloisonnées en deux parties : Java et HTML. Tapestry possède par ailleurs son propre système de vues basé sur les langages XML et HTML.
Et d’un autre côté, les contrôleurs sont de classiques classes Java (des POJOs) et leur gestion simple permet à l’utilisateur de recompiler les classes sans avoir besoin de redéployer l’application.
Les contrôleurs sont par défaut stateless, ce qui se traduit par une réinitialisation des variables entre chaque requête comme expliquée dans la première partie. Toutefois le développeur peut très simplement modifier cet élément à travers l’insertion d’une balise dans le code.
C’est d’ailleurs un des éléments caractéristiques de Tapestry : des annotations légères et souples dans le code au lieu de fichiers de configuration lourds et obscurs.
Ces conventions permettent donc au développeur de ne pas “réinventer la roue” à chaque développement (encore plus qu’avec d’autres frameworks) et de se concentrer sur la partie métier.
Il faut toutefois prendre en compte que Tapestry ne s’occupe pas de la partie gestion de données et qu’il s’intègre naturellement avec Spring et Hibernate, mettant ainsi en place un environnement Java2EE complet et performant.

ZK est un framework web Java peu connu qui est à la fois simple et rapide à prendre en main. Il permet le développement d’applications via la création d’interfaces graphiques.
En effet celui-ci possède des composants par défaut qui permettent de générer des applications Ajax sans écrire une seule ligne de code Javascript. Toutefois si les composants ne suffisent pas à réaliser ces interfaces, le développeur devra écrire lui-même ses composants et donc toucher au Javascript.
Le développement des interfaces avec ZK peut alors s’assimiler à du développement Swing : des classes Java classiques et simples d’utilisations. De plus le développeur peut aussi développer ses interfaces graphiques avec un outil Wysiwyg et/ou en mettant les mains dans les fichiers ZUML qui est un langage équivalent à XML et développé spécialement par et pour ZK.
Comme avec de nombreux frameworks, les applications développées avec ZK s’exécutent sur le serveur et les scripts côté client ce qui permet de limiter les échanges.

Il permet donc de créer des interfaces graphique riches, rapidement et simplement, et dans la plupart des cas de s’épargner l’utilisation du Javascript. Cependant il est très peu utilisé pour une raison simple : ces temps de chargement trop long qui s’expliquent par :
- une mauvaise gestion des accès à la base de données : trop de requêtes.
- des exécutions/chargements globaux et non locaux.

Et ceci défavorise grandement le framework par rapport à ces concurrents pour ce qui concerne le développement d’interfaces complexes.
Pour conclure on peut constater qu’on retrouve ici un problème récurrent lorsqu’on veut trop simplifier le développement. En effet les composants graphiques prédéfinis manquent de personnalisation et ceci impacte sur les performances. Toutefois ce framework reste très intéressant pour développer rapidement des interfaces simples.

Struts Shale est le successeur de Struts mais n’est pas l’évolution de Struts 2.0.
En réalité il n’est pas l’extension de Struts 2.0 tout comme Struts 2.0 n’est pas celle de Struts (voir 1ère partie) mais il reste dans la lignée des Struts et partage des points communs tant au niveau de la manière de développer que de la structure.
Pour être exact,  Shale est une sur-couche à Java Server Faces et fournit des composants graphiques et techniques supplémentaires.
Voici d’un point de vue assez technique, mais sans rentrer trop dans les détails, la liste de ces améliorations :
- Les Beans Java peuvent être liés à une vue JSF.
- Un fichier XML permet de définir l’enchaînement des écrans.
- La partie contrôleur est amélioré (JSF est très orienté vues).
- La partie de validation des actions de l’utilisateur est plus simple à mettre en place.
- Le dialogue entre une page Javascript (AJAX) côté et un Bean JSF côté serveur est facilité.
- Spring est intégré dans Struts ce qui améliore nettement Struts (cf 1ere partie).
- Les pages développées en HTML sont traduites en vues JSF.
- JUnit est étendu.

La création d’un site web à travers les protocoles Ajax et l’écriture de pages jsp (Java Server Page) nécessite des compétences approfondies en javascript de la part du développeur.
C’est un défaut majeur car le but du JavaEE est à la base de pouvoir tout réaliser en Java.
Et c’est dans cette optique que Google a créé le framework Google Web Toolkit (GWT). Ce framework, conçu autour de la technologie Ajax, permet au développeur de réaliser une application Ajax sans écrire aucune ligne de Javascript.
Le principe est simple : le développeur réalise son application en Java et lorsqu’elle celle-ci est prête à être déployé, le compilateur de GWT traduit ce qui doit l’être en Javascript. C’est le cas de la partie cliente de l’application qui peut ainsi être exporté vers n’importe quel serveur Web (Apache, …).
D’un autre côté, la partie serveur s’exécute sur un conteneur de Servlet (Tomcat, …). Par ailleurs la partie cliente peut elle aussi s’exécuter sur un tel conteneur mais uniquement les parties compilables en Javascript peuvent être inclues dans le code de la partie cliente.

Echo2 est un framework développé par la société NextApp. Celui-ci a pour but de faciliter et d’accélérer le développement d’une application web et, tout comme le fait GWT, met en place ce principe à travers un compilateur permettant le passage de Java à JavaScript. Le développeur peut alors réaliser des application Ajax en manipulant exclusivement du Java.
La différence principale entre ces deux frameworks est que Echo2 ne distingue pas la partie cliente de la partie serveur.
Le code d’une application web développé avec Echo2 est intégralement délivré par des servlets ce qui rend impossible l’exportation d’une application développée avec ce framework vers un simple serveur web.

Echo3 conserve l’intégralité des fonctionnalités de Echo2 mais offre une nouvelle couche de conteneur web permettant d’écrire des applications Echo avec le côté client en JavaScript uniquement. Toutefois le développeur peut continuer à développer la partie client en Java (ce qui reste l’avantage de ce type de Framework) et il ne nécessite donc aucune connaissance en HTTP, HTML ou JavaScript pour développer des applications avec Echo3.
Pour terminer sur Echo3 on peut signaler que les applications côté serveur sont exécutées depuis n’importe quel conteneur de servlets et que les applications coté client et serveur se communiquent via XML/JSON via HTTP.

Bibliographie :

http://tapestry.apache.org/
http://gardeux-vincent.eu/Documents/ProjetJEE/SMB_Jaxb_Tapestry/PagesHTML/Tapestry.html
http://www.developpez.net/forums/d902873/java/developpement-web-java/frameworks/autres/zk-zk-framework-ria-pure-java-demande-etre-connu/
http://www.zkoss.org/
http://fr.slideshare.net/louschwartz/pre-yajug-retour-experience-zk20versionyajug
http://www.touilleur-express.fr/2006/03/28/struts-shale-ne-sera-pas-struts-2/
http://hadf.wordpress.com/category/framework/
http://echo.nextapp.com/site/
http://www.jmdoudoux.fr/java/dej/chap-ria-rda.htm
http://echo.nextapp.com/site/echo3

Qu’est-ce que le JavaEE ?

JavaEE, ou anciennement appelé J2EE, est l’acronyme de “Java 2 Platform, Enterprise Edition” qui est une extension de la plateforme de développement Java en une plateforme entreprise dotée de nombreux outils permettant des performances de stabilité, de sécurité et de rapidité que n’offre pas la plateforme classique. Elle permet de développer, de déployer et de gérer des applications basée sur une architecture à 3 couches (type d’architecture basé sur le fait de cloisonner la présentation, le métier et l’accès aux données) et centralisées sur un serveur.

Le JavaEE est donc un ensemble de frameworks (Struts, Spring, Tapestry, etc.) qui permettent le développement web.

Cet article et le suivant auront pour but de vous présenter de manière globale le JavaEE à travers une description succincte de chacun des différents frameworks existants. Nous avons décidé de découper cette présentation du JavaEE en deux parties étant donné le nombre impressionnant de ces composants.
Ce premier article vous présentera Webwork, Apache Struts, Spring, Hibernate et JSF.

Webwork est un framework MVC qui a permis de combler certaines fonctionnalités manquantes à la première version de Struts. N’évoluant plus depuis des années (2006), l’intérêt de présenter ce composant du JavaEE est avant tout historique.

Lors de la création de Webwork, le framework de développement web Java le plus populaire est Struts 1, cependant celui-ci possède des lacunes importantes notamment au niveau de sa gestion de test. En effet pour ce dernier point, Struts 1 a besoin d’un navigateur pour réaliser ces tests contrairement aux développeurs de Webwork qui ont voulu s’affranchir de cette contrainte.

Toutefois Struts 1 est beaucoup trop populaire pour être remplacé par Webwork et une fusion est réalisé entre la première version de Struts et Webwork.
Webwork a fait évoluer le développement Java de manière extraordinaire à travers cette fusion qui a donné la naissance à Struts 2. Il faut cependant savoir que Struts 2 n’est pas une version améliorée de Struts 1 mais plus une version complètement refonte de la première version. On peut même dire que ce framework aurait pu s’appeler Webwork 2 car il hérite plus de Webwork que de Struts 1.

Apache Struts ou Struts 2 est un framework implémentant le modèle MVC2 qui a la particularité de n’avoir qu’un seul contrôleur.

Avec ce framework, le développement d’une application web se traduit par le développement de pages jsp correspondant aux différentes vues de cette application et d’une (unique) servlet correspondant au contrôleur qui accède à la configuration à travers un fichier xml.

Comme dans tout modèle MVC, le but de cette séparation implique que les vues ne contiennent plus de code (ici du Java) mais se composent exclusivement de balises HTML et JSTL ce qui permet de simplifier et de minimiser le développement.
Struts se compose de différents éléments : ActionServlet, Actions, pages jsp et du fichier de configuration struts-config.xml.

Et parce qu’un exemple vaut mieux qu’un long discours, voici le cheminement d’un évènement quelconque provoqué par un utilisateur :
- l’utilisateur effectue son évènement quelconque comme un clic pour changer de page.
- cet évènement se traduit par une requête qui redirige, à travers la lecture du fichier de configuration struts-config.xml, l’Action appropriée (chaque Action à un rôle bien spécifique).
- l’Action appelée traite la requête et renvoie le résultat du traitement sous la forme d’’une page jsp chargée avec certains paramètres qui permettent de répondre à la demande particulière de l’utilisateur.

Spring a pour but de faire le même travail qu’un serveur d’application mais de manière simplifié, c’est ce qu’on appelle un conteneur dit “léger” :
- conteneur dans le sens où il crée les objets les gèrent leurs mises en relation
- “léger” car la prise en compte du framework par les classes se réalise non pas avec l’implémentation d’une interface mais avec un simple import.

De manière plus imagée on peut dire que c’est une fabrique d’objets où les objets sont créées et distribuées à travers l’application, tout ceci grâce à un fichier de configuration xml qui décrit les objets à fabriquer et leurs relations de dépendances.

Spring est très évolué et prend en charge Hibernate, Struts, JSF et d’autres frameworks. Ainsi il faut donc comprendre que l’on se retrouve avec plusieurs couches d’objets gérés par Spring. Le caractère “léger” se montre alors d’un avantage conséquent par rapport aux serveurs d’applications, car cela signifie qu’il est alors possible de remplacer une couche sans impacter les autres.

Spring se base sur les principes du design pattern loC et sur la programmation par aspects ou AOP.

Hibernate est un framework permettant de rendre transparente la couche JDBC (Java DataBase Connectivity) en constituant une couche de programmation au-dessus de ce dernier. Ainsi Hibernate fait le lien entre les objets Java et les informations stockées en base de données.

Avec Hibernate, les accès directs à la base de données sont remplacés par de simple appels à des méthodes objet. Le but étant de manipuler exclusivement des objets et ainsi de s’affranchir de l’aspect relationnel des bases de données qui est fastidieux et répétitif.

Cependant Hibernate n’est qu’un implémentation d’une des JPA (Java Persistence API), APIs qui font le lien entre objets Java et BDD. Mais elle est l’implémentation principale et la plus populaire, ce qui logique si l’on considère le fait que Hibernate existait avant JPA et que les conception de cette dernière se sont inspiré de l’existant.

Hibernate s’utilise avec des fichiers XML ou des annotations directement intégrées dans les classes Java.

Java Server Faces, plus couramment nommé par son abrévation JSF, est un framework basé sur les composants.

La première version sort en 2004 dans le but de développer rapidement des applications web en Java en imposant une séparation nette entre la partie “interface” (ou vues) et la partie “métier” et en proposant une simplicité de développement de l’interface utilisateur avec comme différenciation par rapport à l’existant une base sur un modèle MVC.
Car sans être forcément la plus compliqué à développée, l’interface est souvent la partie la plus fastidieuse et JSF propose des outils pour simplifier de nombreux éléments comme la navigation entre les pages, l’internationalisation, la gestion des composants de l’interface graphique et le développement de nouveaux – plus adaptés à l’application – et même des outils graphiques pour créer plus intuitivement certaines pages de l’application.

De plus JSF utilise des standards mis en place par le JCP (Java Community Process), qui est le W3C du développement Java web, ce point rendant le code du framework plus maintenable et plus sûr. La technologie utilisée est bien entendu côté serveur.

JSF possède de nombreux avantages comme l’intégration dans des IDE permettant un développement rapide, la possibilité de développer ses propres modules mais a aussi des défauts comme l’absence de composants évolués (même s’ils peuvent être développés et ajoutés) ou le manque d’information sur les performances qui ne sont peut-être pas idéales.

Voilà cet article est terminé, le prochain présentera de la même manière Tapestry, ZK, Struts Shale, Expresso, Jena, Echo 2 et 3, Wicket et GWT et par la suite nous essayerons de montrer comment lier certains frameworks afin de pouvoir réaliser des applications web JavaEE en cumulant les avantages de chacun.

Bibliographie :
http://jmdoudoux.developpez.com/cours/developpons/java/chap-hibernate.php
http://www.jmdoudoux.fr/java/dej/chap-hibernate.htm
http://javaweb.developpez.com/faq/javaee/?page=DEFINITIONS
http://www.developpez.net/forums/d262853/general-developpement/alm/architecture/developpement-architecture-3-couches/
http://www.jmdoudoux.fr/java/dej/chap-jsf.htm#jsf
http://www.jcp.org/en/home/index
http://freecode.com/projects/webwork
http://jlafosse.developpez.com/livres/java/struts2/presentation/
http://jean-luc.massat.perso.luminy.univ-amu.fr/ens/java/tp-spring.html
http://ego.developpez.com/spring/

I) Frameworks embarqués

Les frameworks de types embarqués sont ceux qui contiennent un “kit” d’outils complet pour le développement web dès l’installation.

Nous nous intéressons donc à ce type de framework dans cet article.

1) Liste des différents frameworks

Voici la liste des frameworks embarqués les plus connus et utilisés :

a) Play :

Play est un framework web java créé en 2007, et utilisé de plus en plus ces derniers temps . Par exemples de grands sites comme LinkedIn, The Guardian, ZapTravel l’utilisent.

Il est dit tout embarqué car de nombreux frameworks et APIs usuels sont directement intégrés : JPA, Hibernate, EBeans, JUnit, less, CoffeeScript, Selenium, etc.

C’est aussi un framework MVC avec l’architecture classique du modèle MVC :

- Les objets du domaine sont stockés dans app/models

- Les vues sont stockés dans app/views. Elles utilisent le template scala afin de séparer le contenu du code. Cependant il n’est pas nécessaire de connaître le langage scala, c’est le framework qui utilise scala à partir des annotations placées dans les fichiers scala.html et non l’utilisateur qui code en scala.

- Les controllers sont stockés dans app/controllers

Play gère sa propre gestion des dépendances (calquée sur Maven) mais permet d’utiliser Maven directement si l’utilisateur le souhaite.

La grande particularité de ce framework est qu’il n’utilise pas Servlets contrairement à tous les frameworks Java pour le développement web, les créateurs de Play considérant que Servlets est trop lourd.

Un server Play ne conserve pas d’état entre les requêtes (en réalité le scope Flash permet de conserver mais seulement entre 2 requêtes successives ce qui permet de stocker les erreurs), chaque requête qu’il reçoit est indépendante de la précédente. Il est dit “stateless” ce qui est une approche plus fidèle du web et permet d’éviter de nombreux bug comme des désynchronisations entre serveurs, les déconnexions intempestives (pas de limitation technique au timeout), etc.

De plus les ressources de l’application sont identifiées de manière unique par des routes proprement définies.

Play respecte donc l’architecture REST, ensemble de convention et de bonnes pratiques pour ce qui est du développement web.

Un server Play n’a pas besoin d’être déployé. En effet il interpète directement le Java (et non le byte code) : lors de la modification d’une classe Java, le server se retrouver directement modifié. Il n’y a donc pas besoin de redémarrer le server après chaque modification ce qui permet d’économiser un temps de développement précieux.

Une aide au développement un peu curieuse de Play est qu’il génère lui-même lors de la compilation les getters/setters pour tous les attributs publics et traduit les “monObject.sonAttribut” en “monObjet.getSonAttribut()”. Le développement sous Play peut donc se faire avec des attributs publics ce qui permet d’avoir des fichiers contenant uniquement du code “utile” et des appels plus courts aux attributs.

Il encourage aussi la non-utilisation de modèle anémique en simplifiant l’accès aux attributs.

Comme pour le reste, les API utiles pour la réalisation des tests sont directement intégrés :

- JUnit, ce qui implique une plus grande simplicité et facilité lors de la création des tests.

- Selenium, afin de simuler plus simplement l’intéraction homme-machine.

- Les routes sont testables grâce à la compilation du fichier de route en Scala.

Cependant on peut noter quelques mauvais points pour Play :

- La dernière version de Play 2.0 est passé en scala et propose une API Java. Play n’est donc plus un framework Java mais un framework scala. On peut d’ailleurs se demander si Java ne va pas disparaître de Play dans les années à venir.

- Play est encore immature, ce qui implique que les développeurs se permettent de modifier en profondeur leur framework pour le faire évoluer par rapport à leur vision et non par rapport à celles de leurs clients. Ils ont notamment changé le langage du framework ou passé le template Groovy en Scala de la version 1.0 à la 2.0. D’ailleurs ce changement de template a eu pour conséquence la refonte des développements pour passer de Play 1.0 à Play 2.0 ce qui ne se fait pas sans coût

Conclusion :

Sans être pro ou contre-Play, on peut affirmer que ces développeurs se donnent comme mission de faire une remise en cause de l’existant ce qui va être bénéfique au développement web Java. Utilisation systématique de Servlets obligatoires ? Etc.

Si une phrase permet de résumer l’esprit de conception de Play c’est “un framework qui s’adapte au web et non le web qui s’adapte à ce framework”.

b) Stripes

Stripes a été créé en 2005 et utilise le modèle MVC. C’est un framework de présentation permettant de construire des applications web, il utilise les technologies Java récentes afin de faciliter la configuration.

Contrairement aux autres framework java qui nécessitent de configurer de nombreux paramètres complexes, Stripes ne requiert pas de configuration très détaillée.

Il fournit des solutions simples et puissantes aux problèmes ordinaires, ce qui permet de réduire le temps nécessaire à son apprentissage à moins de 30 minutes.

c) Turbine

Turbine est un framework de développement d’applications Web basé sur la technologie Servlets.

Il permet de personnaliser les sites web et d’utiliser les connexions des utilisateurs afin de restreindre l’accès à certaines parties de l’application.

Turbine est développé dans un environnement ouvert, participatif et publié sous la licence

Apache Software License.

Quelques particularités :

-permet de comprendre le système de sécurité de gestion.

- service de programmation.

- serveur de validation de formulaires XML défini.

- service XML-RPC pour les services Web.

Bibliographie :

http://blog.soat.fr/2013/04/redecouvrons-le-developpement-web-en-java-avec-play-partie-1-enfin-un-framework-web-java/

http://www.valraiso.net/play-framework

http://www.playframework.com/

http://blog.nicolashachet.com/niveaux/confirme/larchitecture-rest-expliquee-en-5-regles/

—http://www.stripesframework.org

—http://www.onjava.com/pub/a/onjava/2007/01/24/java-web-development-with-stripes.html

http://turbine.apache.org/

Les Framework JAVA pour le web – Introduction

Introduction :

Un framework est un outil développé dans un langage spécifique permettant au développeur de ne pas à chaque nouveau projet réinventer la roue comme l’accès aux données, le logger, etc. et de développer selon des normes ce qui permet de réutiliser certains morceaux de code. Le but étant de gagner en rentabilité et de ne pas s’attarder sur les tâches rébarbatives pour se concentrer sur les tâches à forte valeur ajoutée.

Les frameworks sont donc répandus dans le monde de l’informatique, et plus particulièrement dans le monde du web les frameworks sont utilisés afin de ne pas implémenter à chaque fois certains points complexes et/ou répétitifs comme les versions de HTML/CSS/Javascript à utiliser, la gestion des différents navigateurs, etc.

Les frameworks Java pour le web sont nombreux et de tout type. En effet on trouve les frameworks de type tout embarqué comme Play et les frameworks orientés J2EE comme Struts, Spring MVC, GWT, JSF, JSTL, etc.

Il serait donc utile de dresser un panorama de ces frameworks afin d’aiguiller les chefs de projets sur les choix techniques du début d’un projet web. Ceux-ci pourront alors connaître le framework convenant le mieux à leur projet, ou s’ils feraient mieux de ne pas utiliser de framework du tout !

Voici une première version du plan :

I) Frameworks embarqués

    1) Description de ces types de framework

    2) Liste des différents frameworks

    3) Comparaison des frameworks entre eux

II) Frameworks “J2EE”

    1) Description de ces types de framework

    2) Liste détaillées des différents frameworks

    3) Comparaison des frameworks entre eux

III) Bilan

    1) Panorama de tous les frameworks Java web

    2) Avantages et les inconvénients de chacun

    3) Lequel choisir selon le type de situation

Bibliographie :

http://www.jmdoudoux.fr/java/dej/chap-frameworks.htm

http://javaweb.developpez.com/actu/45909/Quel-framework-Web-Java-utilisez-vous-principalement-Partagez-votre-experience

Utilisation de moteurs 3D pour la réalité virtuelle

La Réalité Virtuelle

Il n’y a encore pas si longtemps, les auteurs de science fiction imaginaient de voir les hommes évoluer dans un univers virtuel. Un monde artificiel de données où l’utilisateur serait immergé grâce à des interfaces sensorielles pour le son, la vue, et parfois le toucher ou même l’odorat.

Neuromancien de W. Gibson

Neuromancien, de W. Gibson, l'un des premiers romans de SF où le "cyberspace" fait son apparition

Depuis, si la science-fiction n’est pas encore devenue une réalité, la Réalité Virtuelle a grandement profité des progrès technologiques de ces dernières décennies. De nombreuses applications de Réalité Virtuelle ont ainsi pu voir le jour : applications industrielles, simulations, traitement médical, expériences artistiques ou vidéoludiques…

Le Virtual Boy, quand Nintendo s'essaie à la RV et échoue

Seulement, pour fonctionner, une application de Réalité Virtuelle nécessite un important dispositif matériel et logiciel. Nous allons nous intéresser tout au long de cette veille technologique à un élément clé de ce dispositif : le framework de développement 3D.

Un Framework 3D?

En effet, pour modéliser l’univers virtuel, on utilise un framework de développement 3D.
Cet outil propose un large éventail de fonctionnalités que l’on pourra exploiter pour créer l’univers virtuel : un moteur 3D, un moteur physique, un moteur audio, de nombreuses bibliothèques réseau, et bien d’autres choses encore…
De nombreux frameworks existent, notamment dans le cadre du développement de jeux vidéos 3D : Unity, OGRE3D, UDK, UNiGiNE

Un framework 3D comme Unity fournit de nombreux outils pour développer un jeu vidéo.

Utiliser ces frameworks dans la Réalité Virtuelle

Cependant pour permettre à l’utilisateur d’interagir avec la Réalité Virtuelle, il est indispensable d’utiliser un framework 3D disposant de plus de fonctionnalités qu’un framework ordinaire. Certains de ces frameworks sont plus adaptés à la réalité virtuelle que d’autres.
Pour une meilleure application de Réalité Virtuelle, l’outil devrait par exemple prendre en charge les fonctionnalités suivantes…
• La gestion des interactions de l’utilisateur avec la Réalité Virtuelle
• Rendu stéréoscopique
• Rendu multi-écran
• Système de suivi de mouvements de l’utilisateur (ou système de tracking)

Vincent Monier et Raphaël Sfeir, deux élèves de l’École Centrale de Nantes intéressés par un sujet aussi immersif, vont passionnément étudier les frameworks 3D existants pour déterminer lesquels sont les plus adaptés à une application de Réalité Virtuelle et identifier leurs avantages et inconvénients.
Ce projet sera encadré par Jean-Marie Normand, professeur à l’École Centrale de Nantes.