Prise en main de Weblogic Workshop 8.1


Warning: file_get_contents() [function.file-get-contents]: Unable to access .files_menu.inc in /mnt/109/sdb/b/5/nicolas.delsaux/web/script/html_display.php on line 73

Warning: file_get_contents(.files_menu.inc) [function.file-get-contents]: failed to open stream: No such file or directory in /mnt/109/sdb/b/5/nicolas.delsaux/web/script/html_display.php on line 73

Warning: file_get_contents() [function.file-get-contents]: Unable to access .files_menu.inc in /mnt/109/sdb/b/5/nicolas.delsaux/web/script/html_display.php on line 73

Warning: file_get_contents(.files_menu.inc) [function.file-get-contents]: failed to open stream: No such file or directory in /mnt/109/sdb/b/5/nicolas.delsaux/web/script/html_display.php on line 73

Warning: file_get_contents() [function.file-get-contents]: Unable to access .files_menu.inc in /mnt/109/sdb/b/5/nicolas.delsaux/web/script/html_display.php on line 73

Warning: file_get_contents(.files_menu.inc) [function.file-get-contents]: failed to open stream: No such file or directory in /mnt/109/sdb/b/5/nicolas.delsaux/web/script/html_display.php on line 73

Le domaine du développement J2EE a longtemps manqué d'outils graphiques et conviviaux pour le développement d'applications. Associé à Weblogic, Workshop est le premier environnement de ce type disponible pour un serveur d'application. Celui s'appuie de plus pour un certain nombre de tâches sur un framework, Beehive, qui est une surcouche de Struts en corrigeant la plupart des défauts.

Ce document est issu d'une formation à Weblogic Workshop d'une semaine donnée par BEA. Il s'appuie sur mon expérience de développement J2EE pour évaluer, lorsque c'est possible, les avantages et les inconvénients de cette plateforme de développement extrêmement novatrice, ainsi que du framework sur lequel elle s'appuie.

En guise de conclusion, ce document donne les raisons pour lesquelles cet outil pourrait devenir, pour peu que sa fiabilité et son ergonomie soient améliorées, un véritable standard de développement J2EE.

1 Premier jour

Le premier jour de la formation a été consacré à la présentation et à l'installation des différents outils, avec deux ou trois exercices très simples.

Le seul intérêt véritable de cette journée a été la présentation de Workshop. Comme tout le monde ne le sait pas, "Weblogic Workshop" est un environnement de développement pour le web basé sur Weblogic, évidement, mais aussi sur un framework dérivé de Struts, initalement nommé "Weblogic Workshop framework" et libéré (c'est-à-dire placé en Open-Source) par BEA au profit de la fondation Apache sous le nom de "Beehive" (1) (1) : Il y aurait bien des choses à dire au sujet de cette libération, mais ça n'est pas le sujet .

1.1 Présentation rapide de Beehive

Donc Beehive est une extension de Struts censée corriger la plupart des faiblesses du plus ancien des frameworks web.

Ainsi, le contrôleur de Beehive n'est plus un gros et sale fichier XML, mais une classe Java dont chaque méthode est une action. Bien sûr, ça ne suffit pas à en faire un contrôleur complet, donc il faut rajouter au code Java du contrôleur un certain nombre d'extension à la javadoc qui contiennent l'ensemble de la navigation (2) (2) : Là, l'inspiration n'est pas directement Struts, mais un add-on pour XDoclet qui permet de générer les actions du struts-config.xml à partir de tags dans la javadoc de classes d'action Java. .

Par ailleurs, histoire de rendre le choses un peu plus complexes, Beehive ajoute également sa propre taglib nommée "netui", qui fait apparemment la même chose que la JSTL et que la taglib de Struts (c'est-à-dire itérer, afficher du texte formaté ou internationalisé).

1.2 Présentation de Workshop

Workshop, lui, est l'IDE de choix pour utiliser Beehive, car il dispose d'outils graphiques pour modéliser la navigation dans une application, ou pour modifier dans un mode de design les jsps. Graphiquement, Workshop est plus proche de Dreamweaver que d'Eclipse, sans doute en raison du public visé. Car BEA vise plus avec cet outil les utilisateurs de RAD comme Visual Basic ou WinDev que les développeurs hardcore.

L'un des intérêts majeurs, à mon sens, de Workshop, est l'affichage graphique c'est-à-dire dans un beau schéma, de l'organisation de la navigation. Cet affichage permet (enfin) de manipuler proprement une application web sans passer par l'édition, toujours laborieuse, de fichiers XML (3) (3) : En fait, il existait déja un outil pour faire ce type de manipulations : Exadel Struts Studio. Il est toutefois moins intéressant, à mon sens, que Workshop . De plus, cette vue assure une certaine "cohérence" à l'application en empêchant l'utilisateur de faire des choses ... moyennes.

Bien sûr, n'étant qu'en version 1, il n'est pas exempt de défauts (je reviendrai sans doute dessus en fin d'article) (4) (4) : On citera par exemple l'absence d'une liste des fichiers ouverts facilement accessible (les fameux onglets plus ou moins bien codés d'Eclipse, JBuilder ou IDEA), un éditeur Java qui n'égale même pas jEdit ou Jext en mode simple), et certains bugs de jeunesse dont notamment un problème lié à Crystal Reports dont je vous donne la solution : dans votre répertoire "C:\bea\weblogic81\workshop\extensions", localisez le fichier "crystalwlwintegration.jar". Dans ce fichier, extrayez "CRWebLogicIntegrationBundle_en.properties" et renommez-le en "CRWebLogicIntegrationBundle_fr.properties" avant de l'ajouter au jar.Et voilà ! mais ça reste malgré tout un excellent outil, très intelligemment pensé comme on le verra plus bas.

2 Deuxième jour

2.1 Accès aux données : les RowSet Controls

Grâce à son couplage avec Weblogic Server, Workshop peut facilement savoir quelles sont les différentes sources de données disponibles sur le serveur. Cette connaissance va être utilisée pour générer un contrôle d'accès aux bases en trois ou quatre clics (5) (5) : Ce qui est une démonstration flagrante de l'orientation RAD de l'outil. . Là où Workshop est vraiment bien, c'est dans l'utilisation de ces données : en créant un "contrôle", l'encapsulation locale du RowSet, on va pouvoir ajouter, modifier ou supprimer facilement des enregistrements. Mais ça n'est pas tout ! A partir du moment où on dispose de ce contrôle, Workshop peut créer un ensemble de JSPs et d'actions Beehive pour manipuler le RowSet avec le classique CRUD ! C'est-à-dire qu'on va disposer des outils permettant de manipuler facilement depuis le web ces enregistrements. Bien sûr, il manque à ce squelette d'application de nombreuses choses : les contrôles de validité, les règles métier, ... Mais le temps gagné est déjà assez important.

Par ailleurs, on a souvent tendance à craindre les générateurs. Dans le cas de Workshop, il n'y a pas d'inquiétude à avoir : toute cette application a été créée à partir de templates librement modifiables, de manière à donner au développeur toute latitude pour définir son propre modèle de page.

2.2 Navigation et rendu des pages

Après une mise en bouche préalable plutôt sympathique, nous rentrons enfin dans le vif du sujet : la navigation dans le site et l'affichage de contenu dynamique.

2.2.1 La navigation dans le site : les PageFlows

Tous ceux qui ont développé avec Struts savent à quel point la manipulation des différents artefacts du développement peut être risquée, à cause d'un manque de vérification de l'intégrité de l'application. Beehive se propose de supprimer tous ces problèmes, en rajoutant une épaisse couche de propreté sur le bazar que peut être Struts. Pour ça, la "silver bullet" s'appelle PageFlow.

Conceptuellement, un Page Flow, c'est un contrôleur dans le MVC de Beehive. Mais il ne s'agit pas, et de loin, d'un contrôleur analogue à celui de Struts, qui est piloté par un fichier XML. En effet, ce contrôleur est local à la session (il est même contenu dans celle-ci) et peut donc définir comme variables d'instances les variables qu'on plaçait d'habitude en session (avec tous les risques d'incompatibilité de type que ça pouvait impliquer). Dans le même but de simplification, les actions Beehive ne sont plus des classes séparées, qu'il faut référencer dans un gros fichier XML, mais des méthodes d'instance du PageFlow, dont l'appel est évidement plus clair, qui partagent logiquement les variables d'instance de celui-ci, et dont l'organisation est définie par des tags Javadoc. Et enfin, les formulaires ne sont plus non plus des classes séparées, mais des classes internes du page flow.

Tout ça mis bout à bout introduit une simplification remarquable du code, d'abord dans les prototypes des actions. En effet, comme la session et la requête sont des objets implicites du page flow (obtensibles respectivement par un appel à getSession() et un appel à getRequest()), le prototype d'une action Struts se résoud simplement à /** * @jpf:action * @jpf:forward name="success" path="maPage.jsp" */ protected Forward monAction(MonFormulaire form) { Comme on peut le voir, ce prototype est très simple. D'autant plus simple d'ailleurs que le formulaire est déja casté dans le bon type, ce qui est toujours agréable.

Ensuite, trouver les différents forwards disponibles pour les actions se révèle diaboliquement simple. En effet, ceux-ci sont toujours listés juste au-dessus de l'action, ce qui est il me semble nettement plus agréable que d'aller rechercher dans le fichier XML les différents forwards associés, et les JSPs associées aux noms de ces forwards.

Enfin, il est possible d'utiliser plusieurs page flows dans une même session, ce qui permet de découper une application en morceaux, comme par exemple l'authentification, la reconnexion, ou l'achat, afin de la modulariser. D'un autre côté, cette modularité a un coût, puisque ces page flows, pour communiquer entre eux ... doivent placer des objets dans la session ou en base ! A moins bien sûr qu'ils ne préfèrent renvoyer un form bean dans le forward (6) (6) : Ce qui n'est pas réellement facilité par le mécanisme de ClassLoader choisi, qui donne à un page flow la connaissance de son répertoire et de ses sous-répertoires, mais pas celle de ses répertoires parents. Ce qui permet à des page flow contenus de retourner des informations à leur conteneur en utilisant comme action de sortie une action prenant en paramètre un form bean qu'ils définissent. . En tout état de cause, et contrairement à ce que je pensais naïvement, un page flow ne contient pas (au sens d'une variable d'instance) les autres page flows qui peuvent y être lancés, et il ne peut donc pas accéder à leurs variables membres, ni même à leurs méthodes, ce qui aurait pourtant été fort pratique.

Finalement, pour ceux qui souhaiteraient savoir comment ça marche, l'implémentation se base sur deux choses : d'abord, BEA a implémenté un PageFlowRequestProcessor qui permet de donner comme path dans le fichier struts-config les noms des méthodes correspondant aux actions. Ensuite, l'ensemble du XML est généré, comme je l'ai déja dit, par un doclet assez avancé qui va transformer les quelques tags ajoutés en définitions d'actions complètes, et ma foi assez bien écrites.

2.2.2 L'affichage de contenu dynamique : la taglib netui

Comme je le disais plus haut, cette taglib n'est qu'une n-ième taglib d'affichage, d'itération, et d'utilisation du HTML dans les JSPs. Pour plusieurs raisons, je la trouve assez mal foutue.

D'abord, pour lire des valeurs dynamiquement, il faut adresser les différents éléments du contexte de la JSP. Et, chose étonnante, cette taglib n'utilise pas le langage d'expression EL (7) (7) : Celui défini par la JSTL mais une variante, qui n'apporte pas grand chose, si ce n'est les objets spécifiques de contextes de Beehive. Franchement, je me demande bien quel en est l'intérêt.

Autre problème, nettement plus énervant : il n'est pas possible, lorsqu'on itère sur une collection avec un netui:repeater, il n'est apparemment pas possible d'itérer sur un autre objet, sauf si celui-ci est une collection contenue comme attribut sans doute, de la première collection... C'est quand même franchement pénible.

Quant à la partie gestion de templates, il n'y a rien de fabuleux, tant ce type de mécanisme est connu et déja exploité (par exemple, netui-template n'apporte rien par rapport à Tiles, pour Struts). De plus, l'implémentation ne permet pas l'héritage de template (c'est-à-dire définir un template qui est défini pour un certain nombre de ses éléments par un autre template). C'est à mon sens une régression importante vis-à-vis de Tiles, car la définition sous forme d'héritage est éminemment pratique, et peu remplaçable par d'autres moyens.

Bref, globalement, je ne trouve pas que la partie taglib de Beehive soit réellement novatrice.

3 Troisième jour

Après un premier exercice mettant en oeuvre les templates déjà évoqués plus haut, on passe aux forms beans et aux tags associés.

3.1 Gestion des formulaires avec les form beans

3.1.1 Saisie des données dans un formulaire HTML

Pour rappel, les form beans sont l'implémentation locale des ActionForm de Struts. Naturellement, ils sont associés à des formulaires HTML grâce à des éléments de la taglib permettant de créer des checkbox, radio buttons et autres textfields. Lorsqu'on s'en sert dans le mode par défaut, c'est-à-dire simplement, sans aucun javascript modifiant le formulaire, c'est très simple et très efficace, car Beehive dispose de tags permettant de créer automatiquement des listes d'options à partir d'une collection contenue dans l'un des contextes connus.

Malheureusement, comme dans toutes les taglibs, on perd toujours un certain nombre de tags HTML/Javascript souvent utilisés dans les sites dynamiques, je pense notamment à onChange, onBlur, etc ... En fait, ils sont utilisables, mais seulement dans le cas où la liste des options est donnée dans son intégralité, et non par le biais d'une collection dynamique. De plus, les noms générés pour les champs de saisie ne sont pas homogènes. Par exemple, pour un champ ayant comme "datasource" "actionForm.adults", un textfield s'appelera "{actionForm.adults}", un radio button "wlw-radio_button_group_key:{actionForm.adults}" et une checkbox "wlw-checkbox_group_key:{actionForm.adults}OldValue" (8) (8) : Le "OldValue" qui traîne à la fin doit être un bug. . On le voit, c'est assez peu homogène. Qui plus est, on est peu aidé par l'attribut optionnel tagId qui est censé spécifier le tag donné à l'input, mais qui en fait se contente de rajouter une couche d'abstraction par le biais d'un javascript assez peu fiable (9) (9) : Si par exemple l'id qu'on souhaite donner contient un ".", le javascript plante. .

3.1.2 Validation des données

Comme la plupart des éléments de Beehive, la gestion des erreurs de validation est issue de Struts. Et cette fois la descendance est directe : on retrouve en effet dans les form beans une méthode "validate", avec un prototype légèrement différent, mais retournant toujours un objet ActionErrors. Bien sûr, il y a quelques améliorations, comme par exemple la déclaration de la page d'affichage d'erreur par le biais d'un tag javadoc, ou des tags d'affichage des erreurs plus utilisables. Mais il n'y a pas là de différence notable.

D'autres éléments sont également disponibles, comme le tag getData, qui permet de placer des éléments du page flow dans le pageContext. Quel est l'intérêt ? Pouvoir faire des tests sur les valeurs d'éléments du page flow afin de modifier l'affichage de la page. En fait, c'est une façon, assez peu élégante car elle impose l'intégration de scriptlets dans les jsps, de remplacer, par exemple, les tests disponibles dans la JSTL. En effet, on ne dispose pas dans Netui de tags de tests. Ceux-ci doivent donc être faits en Java, sur les objets disponibles dans le contexte de la JSP. Ce contexte n'est pas celui de XScript, mais celui défini par J2EE. le page flow n'y figurant pas, il faut d'abord déplacer ses éléments dans ce contexte. Bref, beaucoup de bruit pour pas grand chose.

3.2 La sécurité

Y a-t-il quoi que ce soit à dire sur la sécurité dans Workshop ? Non, car celle-ci est très exactement celle qui est définie par la norme J2EE. Bon, en fait, ça n'est pas tout à fait exact. Beehive, dans son entreprise de suppression du struts-config, a encore une fois défini la gestion des rôles autorisés pour des actions sous forme de tag Javadoc. Il existe donc pour les actions nécessitant une authentification un tag, utilisé pour générer l'attribut "roles" dans le struts-config. Pour être tout-à-fait complet, cet attribut peut être édité en utilisant l'onglet "propriétés" de Workshop.

4 Quatrième jour

4.1 Les contrôles de base de données

Avant d'en venir au cas particulier des bases de données, il faut d'abord évoquer ce que sont les contrôles. Si Struts a pour ambition de ne traiter au sein du modèle MVC que les parties Vues et Contrôleur, Beehive va plus loin en définissant un mode générique de connexion au modèle. Ce mode passe par ces fameux contrôles. En fait, plutôt que d'accéder directement à une base de données, un EJB ou un système de MOM, on va passer par un objet de type contrôle qui, lui, se connecte à la base de données ou à l'EJB. Cet objet, comme tous les autres objets d'une application Beehive, sera utilisé dans le contrôleur, c'est-à-dire dans le page flow, sous la forme d'une variable d'instance, instanciée lors de l'exécution pour le framework.

Dans le cas particulier du contrôle de base de données, celui-ci est encore une autre implémentation d'un mapping objet-relationnel, assez intelligente dans sa conception, même si ce contrôle souffre de quelques faiblesses, peu gênantes toutefois dans le cadre de Beehive. En fait, pour obtenir son mapping objet-relationnel, Beehive définit chacun des contrôles comme une interface étendant "DatabaseControl". Dans cette interface, est associé à chaque méthode au moins un tag spécifique, "@jc:sql statement=" qui définit le code SQL associé à cette méthode. Dans le même ordre d'idée, la datasource utilisée est donnée dans la javadoc de l'interface. Pour l'instant, ça peut sembler assez faible. Là où ça devient plus intéressant, c'est que ces contrôles intègrent un mécanisme analogue à Apache DBUtils permettant de mapper les champs d'une table avec les variables membres d'une classe Java. Et pour plus de puissance encore, Workshop est capable, pour accéder à une table particulière d'une base, de générer complètement le contrôle permettant d'y accéder, ainsi que l'objet Java représentant une ligne de cette table.

Bien sûr, cet outil supporte aussi bien les lectures que les écritures (ce qui est un avantag par rapport à DBUtils). En revanche, le mapping est assez lâche. Il n'y a en effet pas d'écriture automatisée des objets Java dans la base lorsqu'ils ont été modifiés. Il faut donc toujours penser à invoquer les méthodes de sauvegarde des objets pour pouvoir les écrire en base, ce qui est à mon sens moins puissant que les outils comme JDO ou Hibernate, même si ça n'est pas réellement gênant. Une autre chose nettement plus étrange est la visibilité choisie pour les méthodes de l'interface du contrôle : elles ont la visibilité par défaut ! Pour une classe, ça les rendrait visibles seulement dans le package. Seulement voilà, il s'agit d'une interface. Et la visibilité par défaut est public. Personnellement, j'aurais préféré que le générateur donne explicitement une visibilité public. Mais bon, ça marche ...

Les contrôles de base de données sont ainsi assez bien fichus. Toutefois, il existe des cas où on souhaite encore plus d'assistance. Dans ce cas, le RowSetControl est parfait. En effet, celui-ci, à partir de la donnée d'une table dans une base de données, va générer l'ensemble des méthodes du contrôle permettant un accès CRUD (Create, Read, Update, Delete). Outre l'interface Controller, ce contrôle étend ResultSet, ce qui permet de retrouver les fameuses méthodes getString("MA_COLONNE") qui ont fait le bonheur de bien des développeurs. Il est par ailleurs associé à une taglib, permettant de faciliter son rendu dans une table triable.

4.2 Intégration à un système d'information

Grâce à la norme JCA, les serveurs d'application J2EE doivent disposer d'outils permettant d'interagir avec le reste du système d'information. C'est évidement possible, et évidement facilité, dans Workshop, grâce aux "applications view controls". Comme leur nom l'indique, il s'agit de contrôles permettant d'accéder à l'application grâce à une interface simplifiée.

En effet, la communication avec les applications externes se fait par le biais de fichiers XML, ce qui est toujours assez peu pratique. Ici, on va utiliser des XMLBeans. Ceux-ci sont des classes Java générées à partir du .xsd (le XML Schema) définissant la syntaxe de cet appel. Il n'y a ainsi plus besoin de générer de fichier XML à la main : on appelle à la place des méthodes de classes Java générées qui reprennent l'arborescence du document, mais aussi les règles définissant l'organisation du message. Leur manipulation est excessivement simple, et permet un contrôle via la compilation garantissant que le document XML qui sera généré sera bien formé et valide selon son schéma.

4.3 Web services

Evidement, Weblogic ne pouvait pas passer à côté des services web, qui sont l'un des plus importants moyens de l'interopérabilité. Workshop fournit à ce titre des assistants de création de web services à partir de méthodes Java, grâce à un format spécifique. De la même manière, il est possible d'encapsuler très facilement un service web dans une page, grâce au contrôle service web. (10) (10) : N'ayant aucune expérience sur le sujet, je n'ai pas d'avis sur les qualités et défauts éventuels de Workshop à ce sujet.

5 Cinquième jour

5.1 Les contrôles custom

Comme on l'a vu plus haut, les contrôles représentent la couche modèle au sein du MVC de Beehive. Et tout comme la partie contrôleur peut être composite grâce aux nested page flow, le modèle peut être composite en utilisant ces contrôles. Un contrôle custom est donc un ensemble composé d'une interface et d'une implémentation, sous forme d'une simple classe Java. Rien d'inventé en apparence. En fait, le secret, c'est que la classe implémente, outre l'interface définissant le contrôle, une interface "Control" qui fait que Workshop la détecte comme étant un contrôle. Par ce biais, le contrôle custom, qui référence d'autres contrôles, peut être facilement ajouté à un page flow et instancié.

Rien de révolutionnaire, donc, mais juste une fonctionnalité indispensable pour de la bonne programmation, définie de la bonne manière (11) (11) : Pour l'implémentation, c'est moins sûr : l'exercice auquel j'ai eu affaire refusait de fonctionner correctement pour une sombre histoire de déploiement mal contrôlé.

5.2 L'intégration des EJB à Workshop

Dans la mesure où Workshop est un environnement de développement complet, il ne pouvait faire l'impasse sur les EJBs. Pour cela, il propose plusieurs outils : d'abord, les projets EJB (12) (12) : sur lesquels je ne m'étendraient pas, car ils ne font pas partie du cours puis les contrôles EJB qui permettent d'utiliser facilement un EJB dans un page flow (en évitant le lookup JNDI).

5.3 La gestion de processus métiers

La modélisation de la circulation de l'information dans l'entreprise est un champ d'étude excessivement riche en informatique. Et y apporter une réponse peut sembler excessivement ardu. Toutefois, Workshop s'y emploie grâce à une série de composants permettant de modéliser simplement les différentes opérations d'un processus. En fait, on y retrouve les grands classiques : tests, opérations en parallèle ainsi que deux types d'appels : celui d'un web service, et celui d'un page flow. C'est simple à développer (grâce à un puissant éditeur avec drag'n'drop), c'est élégant, et ça marche sur tout navigateur. Ca permet donc à tous les acteurs d'un processus de simplement consulter l'état de celui-ci sans installer d'application lourde. Bref, j'ai trouvé ça très intéressant, même si la formation, par manque de temps, n'a pu couvrir ce point en détail.

6 Conclusion

Workshop et son framework sont deux outils très riches, pour lesquels il me semble assez difficile d'exposer avec justesse les avantages et les inconvénients. Toutefois, après une semaine d'utilisation, voici les quelques remarques que j'aimerais faire les concernant.

D'abord quelques remarques d'ergonomie concernant Workshop. Il est troublant, lorsqu'on arrive d'un outil (Eclipse) dont certains éléments d'interface sont devenus pour tous les utilisateurs des standards, de ne pas les retrouver ailleurs. Je citerais par exemple les onglets de documents ouverts, le double-click sur l'onglet maximisant le document, et tant d'autres détails. Ceux-ci n'empêchent pas l'utilisation de Workshop, mais la contrarient car ils font perdre du temps au développeur. Dans le même ordre d'idée, il serait bon de se mettre d'accord entre éditeurs sur les touches utilisables en mode debug; pour l'un c'est F5, F6, F7, F8, pour l'autre F10, F11 et F12, et pour un troisième F5, F6, F7, F8 mais pas dans le même ordre (je cite ici de mémoire Eclipse, Workshop et JBuilder, trois outils qu'un développeur Java s'attend à utiliser de temps en temps). Bien sûr, tout ça n'est pas vraiment rédhibitoire, mais ça fait mauvais effet. Ce qui l'est plus, en revanche, c'est l'éditeur Java, tellement pauvre qu'il force quasiment l'utilisateur à se construire un projet Eclipse ou NetBeans, où à lancer emacs bien configuré, pour afficher les classes Java avec une coloration syntaxique, une complétion et des outils (comme le refactoring) dignes d'un outil professionnel. En effet, de ce point de vue là, Workshop est à peine digne d'éditeurs "simples" comme JEdit ou Jext (avec en plus la restriction que ceux-ci supportent de nombreux plugins pour en faire de vrais outils de développement, là où Workshop est franchement fermé). Bref, si Workshop est parfait pour définir à grands coups de drag'n'drop les différentes actions d'un page flow et pour construire une jsp de la même manière, il est en revanche très faible dès qu'on sort de ce cas d'utilisation.

En revanche, Beehive est à mon sens la vraie technologie gagnante de Workshop : c'est un framework élégant, qui gomme 80 % au moins des faiblesses conceptuelles de Struts, et qui accélère d'une manière spectaculaire (en conjonction avec Workshop) le développement. Bien sûr, il a quelques points faibles, comme la taglib qui n'est pas à mon sens digne du reste du framework, et gagnerait largement à être remplacée par une version spécifique de la JSTL. En revanche, les page flow sont un vrai bonheur, les contrôles sont intelligemment pensés (surtout ceux s'occupant de mapper une base de données relationnelle), et la définition d'objets de gestion de formulaire est d'une simplicité biblique. De plus, son passage en Open-source en fait à mon sens le successeur officiel de Struts. Enfin, grâce à l'implémentation choisie (qui est complètement compatible avec Struts) utiliser Beehive sur un serveur disposant de Struts doit être également très simple. Il n'y a donc pas à hésiter : il faut à mon avis investir dans Beehive qui est facile à apprendre, aussi puissant (voire même largement plus) que Struts, et franchement plus agréable.

Donc si Workshop a bien du souci à se faire quant à son utilisation, Beehive est en revanche bien parti pour devenir le nouveau standard du développement d'applications web J2EE.