Développement Web avec le framework JBoss Seam

Ce chapitre complète l’outillage Web Tools avec Seam, un framework « Web 2.0 Ready », qui facilite le développement JEE, en particulier pour les applications fondées sur les technologies JSF et EJB3. Après un bref rappel de la genèse des frameworks JEE et des fondamentaux du framework Seam, vous mettrez en oeuvre ce dernier sur l’étude de cas. Les frameworks J2EE Depuis la fin des années 1990, les best practices de développement Java/J2EE, ont imposé, bien avant l’apparition des frameworks tels que Struts ou Spring, une approche de développement en couches : couche présentation, couche métier et couche d’accès aux données et de persistance, comme l’illustreCette approche en couches s’appuyait sur les API de base des servlets. Une servlet traite les requêtes Web en entrée et affiche le résultat sous forme de balises HTML, qui permettent l’affichage de pages au sein d’un navigateur.

L’inconvénient de cette approche était que les balises HTML chargées de la présentation étaient mêlées à du code Java, ce qui impactait fortement la maintenabilité de l’ensemble et ne permettait pas une répartition efficace des rôles au sein de l’équipe projet (designer de pages Web et développeurs Java). Est ensuite venue la technologie JSP (JavaServer Pages), qui permet aux développeurs d’embarquer des éléments dynamiques au sein de pages HTML. Ces éléments dynamiques utilisent des balises spécifiques (directive d’import, de code Java à exécuter, de résultats à afficher, etc.), ainsi que des variables implicites (request, response, session, etc.). Bien que mieux structurée que les servlets, cette approche de développement présentait plusieurs inconvénients, le principal d’entre eux étant le manque de lisibilité du code du fait du mélange du HTML et du Java, d’où une confusion entre la présentation et la logique applicative. Le framework Open Source Struts de la fondation Apache est ensuite apparu au début des années 2001. Dédié à la conception d’applications Web à base de servlets, de JSP et de JavaBeans, ce framework fonctionne schématiquement comme illustré.

Conformément au modèle appelé MVC2, Struts s’appuie sur une classe principale, la classe org.apache.struts.action.ActionServlet, qui assure le rôle de contrôleur. Celle-ci est associée à toutes les requêtes HTTP se terminant par .do via la configuration du fichier de mapping associé (balise <servlet-mapping>). En plus de cette classe, un fichier de configuration struts-config.xml contient une liste d’URL dédiées chacune à une action. Pour transférer les données du formulaire à l’action, Struts utilise une instance dérivée d’ActionForm. Le lien entre cette instance, l’URL demandée et l’action est aussi défini dans le fichier de configuration Struts. Côté modèle, Struts n’impose rien, et aucune classe n’est fournie, laissant une totale liberté de choix des technologies à utiliser pour l’implémentation du modèle (ce qui est naussi un inconvénient dans la mesure ou aucun standard n’est proposé pour organiser cette partie du développement). Peu de temps après sont apparues les premières implémentations Sun des spécifications JSF (JavaServer Faces) ⎯ JSR-000127. Conçues pour le développement rapide d’applications Web, ces spécifications proposent une interface graphique riche associée à une logique de programmation événementielle. Pour cela, la norme définit un cycle normalisé detraitement des requêtes et fournit une abstraction complète du protocole HTTP. En découle une gestion transparente de l’état des composants. En comparaison de JSP, de l’API servlet et de Struts, qui oblige les développeurs à produire beaucoup de code pour gérer les aspects présentation, interaction et ergonomie, les composants JSF prennent en charge automatiquement ces opérations.

Limitations de Struts et JSF

Le framework Struts est aujourd’hui déprécié du fait des nouveaux besoins des applications Web 2.0 complexes. Les raisons à cela sont nombreuses. Citons en vrac l’absence de formulaires de type stateful permettant la conservation des états et une gestion du contexte évolué, le fait qu’une seule JSP soit associée à un unique form bean (bean associé à un formulaire), qu’une seule classe Action puisse mapper un form bean pour chaque configuration, sauf à passer par des solutions de contournement difficilement maintenables, etc. Ces limitations ont favorisé l’émergence de JSF, qui propose une approche plus orientée omposant, se rapprochant d’une approche davantage RAD et à la .Net. Par contre, toute la « plomberie » nécessaire à l’invocation des méthodes et des services métier avec EJB3 ainsi que la gestion des sessions reste à la charge du développeur, ce qui complexifie grandement le développement d’applications JEE.