Par DreamSoft
"Complexe", "lourd", "exigeant au regard des compétences des équipes en place"… Voilà quelques uns des jugements que motivent historiquement J2EE et les outils associés quand une entreprise s'interroge sur son prochain modèle de développement.
Cette difficulté des outils J2EE à vulgariser la puissance du modèle de développement est devenue d'autant plus flagrante avec la montée en puissance de Microsoft .Net.
Inévitablement, Visual Studio .Net, et notamment sa capacité à réconcilier programmation événementielle et développement Web, appelait une réplique des acteurs J2EE. C'est aujourd'hui chose faite avec les JSF (Java Server Faces), un nouveau standard J2EE qui entend remettre au goût du jour un vieil acronyme de l'informatique : RAD pour Rapid Application Development. Explications.
Standardisé et implémenté à travers plusieurs outils, JSF affiche une louable ambition : permettre (enfin) aux développeurs J2EE de renouer avec la programmation événementielle. Plus concrètement, les JSF offrent de bâtir des interfaces Web riches de façon visuelle et sans nécessiter la connaissance pointue d'un framework.
La source d'inspiration des JSF est évidente - les WebForms de .Net se caractérisent par leur capacité à rapprocher client Web et programmation événementielle - et les objectifs sont limpides : réussir à séduire une cible de développeur que la complexité de J2EE et des frameworks tels que Struts a laissé sur le banc de touche.
Sun, grand promoteur des JSF, pense sans doute aux développeurs PHP et probablement, dans ses rêves les plus fous, aux développeurs VB… L'objectif est-il atteint ? Les outils implémentant JSF peuvent-ils être qualifiés d'outils RAD ? C'est entre autres ce que nous avons souhaité évaluer en confiant à plusieurs développeurs la prise en main approfondie d'outils tels que Sun Java Studio Creator, IBM Websphere Studio Application Developper 5.1.2 et JBuilder 2005.
Au-delà de l'implémentation des JSF, ces outils proposent des environnements qui les destinent à des usages différents. Et c'est pour couvrir l'ensemble des usages que nous avons aussi ajouté à cette évaluation BEA Workshop 8.1, même si, pour l'heure, ce dernier n'a pas encore implémenté les JSF.
L'objectif n'est donc pas ici de "noter" ces outils ou de comparer des outils concurrents (ce qu'ils ne sont pas). Il s'agit plutôt de cerner les usages respectifs de ces environnements au-delà de leur quête commune : améliorer la productivité du développeur et démocratiser la puissance du modèle J2EE. Dernière précision, nous avons pris soin de confier cette évaluation à la fois à des "vieux" Javaïste et à des développeurs plus familiers de .Net que de J2EE, cela afin de croiser les points de vue.
Sun Java Studio Creator
Le petit nouveau de Sun se veut le héraut du standard JSF et, c'est le moins que l'on puisse dire, cela se voit dès le lancement de l'outil. Et pour cause : Java Studio Creator met en œuvre exclusivement les JSF et JSP. Hors de question donc avec cet outil de se lancer dans le développement d'EJB. Java Studio Creator est exclusivement dédié au développement d'applications Web.
Accompagné d'une documentation et de tutoriaux particulièrement bien construits, Java Studio Creator permet de s'abstraire des concepts J2EE. Certes, la connaissance des concepts J2EE est appréciable mais elle ne s'avère pas incontournable pour prendre en main l'outil et mener des développements.
Plusieurs templates fonctionnels (page de redirection, d'erreur) sont fournis pour rapidement assembler un projet. Bien agencé, l'espace de travail met à portée de "drag and drop" la bibliothèque d'objets JSF et affiche l'essentiel : un explorateur projet, les connexions aux bases de données ou encore l'arborescence des pages. La composition de ces dernières s'opère en mode Grid Layout (positionnement des éléments dans un tableau) ou Flow Layout (positionnement absolu des éléments). La palette des composants est bien catégorisée tout comme les fenêtres de propriétés qui classifient bien les différents types d'événements (JSF, Javascript..). Il est aussi possible d'ajouter des scripts côté clients (les fameux "Snippets" ici appelés "Clips").
Côté productivité, les classiques sont présents : complétion automatique du code, signalisation de syntaxe incorrecte. De même pour les schémas XML - notons en revanche que l'outil ne permet pas de valider un document au regard d'un schéma. Une fois généré, les WAR sont automatiquement déployé sur le serveur d'applications (Sun Application Server) qui accompagne l'outil (aussi livré en outre avec la base de données PointBase).
In fine, nous avons-là un outil réellement RAD mais dont le champ d'action se limite strictement aux applications Web. Résultat, les développeurs .Net ont apprécié ; les développeurs Java, quant à eux, se sont vite sentis à l'étroit…
IBM Websphere Studio Application Developper 5.1.2
Véritable couteau-suisse du développement J2EE et grand frère d'Eclipse, IBM WSAD implémente de façon plutôt exhaustive les standards J2EE (JSP, JSF, EJB) et les frameworks (Struts notamment). Si cette exhaustivité peut dérouter dans un premier temps le néophyte, elle rassure en revanche l'habitué qui, rapidement, peut personnaliser son environnement en fonction de son projet (projet EJB, projet Web dynamique…).
Une fois le type de projet sélectionné, il est encore possible de jouer avec les multiples perspectives qu'offre l'outil, lesquelles permettent de voir le projet sous différents angles (données, Web, debug…). A condition de bien personnaliser l'outil (par exemple en enlevant les palettes relatives aux ressources Struts), il s'avère donc possible de se retrouver dans un environnement qui permet de travailler efficacement dans un projet strictement JSF.
L'implémentation du standard est de bon niveau : un simple clic sur les objets disposés dans une page permet d'accéder aux événements, qu'il s'agisse de côté Java s'exécutant côté serveur ou de code Javascript fonctionnant côté client. Le tout cohabite avec un designer de page qui permet de s'abstraire de tout codage HTML. L'écriture de code Java est soutenue par tous les mécanismes habituels (complétion, signalisation de syntaxe incorrecte…).
La génération de schémas XML est également très bien entourée, l'édition pouvant s'effectuer en mode source ou graphique. Bref, on le comprend rapidement, WSAD peut sans ambiguïté endosser les attributs d'un outil RAD. Face à Sun, IBM n'a pas à rougir de son implémentation technique des JSF.
Cependant, l'environnement, dont le champ d'action est bien plus vaste que celui de Sun Java Studio Creator, est moins lisible d'emblée pour un développeur qui n'est pas familier de J2EE et de ses frameworks. Quant aux développeurs J2EE, plus expérimentés, une question s'impose : l'outil valorise-t-il suffisamment les JSF pour qu'ils prennent le temps de s'y attarder ?
Borland JBuilder 2005
Impossible d'évaluer des outils de développements J2EE sans inscrire sur la liste le seul éditeur qui fournit à la fois des outils J2EE et .Net. D'autant plus quand cet éditeur est un acteur historique des outils de développement. Le premier adjectif qui vient à l'esprit pour qualifier JBuilder 2005 est "complet". A l'instar d'un WSAD, JBuilder est conçu pour tirer parti de J2EE de façon exhaustive mais, revers de la médaille, sans chercher à s'abstraire de la complexité du modèle.
Bref, une connaissance approfondie de J2EE est ici nécessaire pour domestiquer cet outil qui, par ailleurs, est aussi conçu pour s'intégrer au mieux avec les autres outils de Borland tels que Together (pour la conception et la modélisation) ou encore Optimiseit (pour l'optimisation du code). Indéniablement, l'outil est conçu pour un usage avancé.
En témoigne par exemple la mise à disposition de fonctions de refactoring (renommage d'objets, extractions de méthode d'une classe pour créer une interface…). Bref, l'environnement est exhaustif et sophistiqué. Sur le front du RAD en revanche, le bilan est moins glorieux : nous sommes loin, très loin même, d'un environnement de développement visuel.
Même la conception des pages Web passe par l'édition du code source (il faut jouer avec la prévisualisation pour contrôler le résultat). Quant aux JSF, l'implémentation nous a laissée pour le moins perplexe. Certes, la spécification est bien présente dans l'outil.
En d'autres termes, JBuilder 2005 comprend bien le code des JSF. Problème : leur mise en œuvre ne laisse pas d'autres choix au développeur que de travailler au niveau du code source. Il n'est nullement possible d'ordonner les contrôles de façon visuelle. Bref, les JSF sont bien là mais n'améliorent nullement le caractère RAD de l'outil. Difficile de ne pas se demander pourquoi Borland a pris la peine d'implémenter de la sorte un standard dont le principal mérite est de faciliter le développement visuel…
Au final, JBuilder 2005 confirme par sa complétude son statut d'IDE J2EE historique. Un outil puissant qui, pour l'heure, ne semble pas pressé de séduire une cible plus large que celle des développeurs J2EE très expérimentés.
BEA Workshop 8.1
BEA Workshop est un cas à part dans notre évaluation puisque, si les 2 autres outils d'IBM et de Sun sont des produits autonomes, l'environnement de BEA est généralement utilisé pour travailler avec le portail (Weblogic Portal) ou encore avec l'offre d'intégration (Weblogic Integration) de BEA. En outre, BEA Workshop 8.1 ne met pas en œuvre pour l'heure les JSF. Cependant, BEA a travaillé, bien avant l'arrivée des JSF, sur des composants ("pageflow", "widgets" et autres "contrôles") qui permettent en partie de faire abstraction de la mécanique J2EE.
A l'instar des autres outils, des assistants permettent de sélectionner un type de projet (Web, EJB, Portail…) afin d'amorcer son squelette. L'outil ne supportant pas les JSF, le développeur reste ici dans la philosophie du framework Struts. La complexité de ce dernier est cependant plutôt bien masquée, notamment via la notion de "pageflow" qui représente une abstraction des interactions entre les pages Web et les contrôles métier.
La manipulation de ces composants de pageflow simplifie grandement le développement d'une application Web qui, pourtant, met bel en bien en œuvre un modèle MVC. Dans le même esprit, la manipulation de "widgets" réduit le code à écrire pour gérer les interactions client. Ces différents contrôles, qui permettent de s'abstraire des mécanismes J2EE, ponctuent l'ensemble du développement.
Qu'il s'agisse de manipuler des Web Services, d'accéder à une base de données ou encore de communiquer avec un bus de message asynchrone, pour chaque cas, le Workshop propose un type de contrôle qui épargne au développeur la programmation de bas niveau. En ce qui concerne l'édition et la manipulation des schémas XML, il faut s'en remettre à l'outil XML Spy inclus dans le package et dont les fonctionnalités sont assez basiques.
Dans la pratique, le caractère plutôt visuel de BEA Workshop peut s'avérer trompeur : si l'outil ne nécessite pas une maîtrise des mécanismes J2EE de bas niveau, une bonne connaissance du framework J2EE s'impose pour tirer parti de la puissance de l'outil et utiliser à bon escient les contrôles proposés. Certains (ceux qui sont venus à J2EE à travers la plate-forme BEA) louent cette " BEA touch " ; d'autres y voient une dérive propriétaire. Une question, là encore, de culture...
En conclusion
Nous l'avions clairement annoncé en introduction : nous avons évalué des outils moins concurrents que complémentaires car s'adressant à des populations et à des usages distincts.
Sun Java Studio Creator présente un pouvoir de séduction indéniable pour des développeurs Web encore peu aguerris à J2EE. IBM WSAD et Borland JBuilder 2005 s'adressent sans aucun doute à une population plus chevronnée qui ne se limitera pas à des applications Web.
Enfin, BEA Workshop, même s'il ne s'appuie par pour l'heure sur les JSF, se caractérise par une simplification sensible de la manipulation des mécanismes J2EE. Certes, de part ses liens avec les autres briques de la plate-forme BEA, Workshop occupe une place à part dans le paysage des outils. Cependant, rappelons que le framework sous-jacent au Workshop a été placé sous une licence open source par BEA, projet connu sous le nom Beehive. BEA s'est rapproché de la fondation Apache comme du consortium Eclipse pour rendre interopérable ce framework avec le serveur d'applications de la première et avec l'outil de développement du second.
Autrement dit, il existe de bonnes chances aujourd'hui de voir les apports du Workshop profiter à une plus large audience. Des apports qui ne représentent pas une alternative aux JSF mais plutôt un complément : la valeur ajoutée des JSF concerne en premier les événements visuels (graphiques) tandis que la valeur ajoutée de Struts, tout comme celle des contrôles inaugurés par BEA dans son Workshop, se trouve plutôt du côté des contrôles métiers (applicatifs).
En fait, à eux quatre ces éditeurs mettent en œuvre au profit du modèle J2EE une stratégie tout à fait semblable à celle que Microsoft prépare pour .Net. L'année 2005 verra en effet du côté de Microsoft l'apparition d'un Visual Studio 2005 qui devient la pierre angulaire de la plate-forme .Net (et plus largement de l'offre Windows, de Office à l'offre d'EAI Biztalk) et qui , en même temps, sera décliné dans des versions "Express" correspondant à des besoins précis (développements Web, développements VB…).
Manque seulement au clan J2EE un peu d'unité pour assurer la convergence (ou l'interopérabilité) des différentes initiatives (Struts, JSF, Beehive…) et promouvoir de façon cohérente l'évolution du modèle.
|
