Seam + ExtJS, fondations

Après avoir pas mal recherché d'informations sur Internet à propos d'une intégration possible de Seam et ExtJS, il est apparu qu'aucun exemple de code ne circule ni même beaucoup de conseils en terme de conception.

Maintenant que j'ai un prototype qui fonctionne, je vais écrire quelques articles montrant pourquoi ce choix de technologie, comment le faire (avec de la théorie et du code source d'exemple), et aussi comment cela se passe sur un projet d'entreprise (montée en compétence sur cette technologie, limitations, bugs encore présents, etc), et enfin je pourrais donner des indications en terme de performances.

Pour commencer, ce premier article montre comment je compte lier ces deux frameworks prometteurs.

En premier lieu, mon souhait est de réhabiliter le poste client. Généralement on se contente de lui faire afficher les fichiers HTML, d'exécuter quelques javascripts simples pour valider les données saisies puis de soumettre le formulaire au serveur d'application en attendant d'afficher une nouvelle page complète.

Pour moi, le défaut de ce design est d'introduire une couche applicative relativement complexe, la couche de présentation, pour pouvoir manipuler ces soumissions de formulaires. Bien sûr de nombreux frameworks existent, comme Struts ou JSF, mais ils restent tout de même relativement lourds et représentent une part importante dans le temps de développement d'une application.

De plus ce mode de fonctionnement oblige à envoyer l'ensemble des données du formulaire au serveur d'application qui renvoie l'ensemble du code HTML à afficher côté client. On observe à cause de ce mécanisme :

• une complexité accrue dans la gestion de l'état de la page : une donnée chargée pour être affichée dans la page dans un temps t0, pour ne pas avoir à être de nouveau chargée, doit être gérée dans un cache : par exemple dans un viewstate (applicable à jsf ou asp .net) ou alors un cache applicatif qu'il faut aller consulter lorsque l'on construit la page (Struts + jsp par exemple)
• des pertes de performance et de ressources notables car d'une part on fait transiter sur le réseau des données inutiles (des données de formulaires inchangées, puis des blocs complets d'html non modifiés...), et d'autre part on s'oblige à valider côté serveur des données qui n'ont pas lieu d'être (encore une fois ces données de formulaire inchangées...) !

Mon souhait est donc d'évincer cette couche applicative et de rendre au client le rôle de contrôleur. Avec les technologies Ajax il est désormais possible d'effectuer un grand nombre d'actions sans pour autant avoir besoin de faire des soumissions de formulaires HTTP tout en limitant les données en transit au minimum nécessaire.

Dans ce cas de figure, le serveur d'application se contente d'être un serveur de services (on s'oriente donc vers une architecture de type SOA), en exposant une "façade web" à ses services métiers. Ces façades se contentent de centraliser la sécurité d'accès aux services, de gérer les exceptions métier et de remonter les objets et messages au client javascript. Ainsi pour un même service métier, on pourrait avoir une façade webservice et une autre façade Seam Remoting.

C'est là qu'entre en jeu Seam Remoting : plutôt que d'utiliser un webservice comme source de données aux composants clients ExtJS (relativement lourd à mettre en place côté serveur comme côté client), nous allons utiliser la possibilité d'interroger à distance un Session Bean (avec en plus la possibilité de s'inscrire dans un contexte de conversation).

Pour information et pour avoir une idée de ce que je tente de faire sur ce prototype voici une copie statique de l'interface :

La liste est chargée en consultant un SessionBean (EJB 3.0), la pagination est activée ainsi que la possibilité de trier les colonnes et de grouper les lignes selon un critère.

Quant on clique sur une ligne, son détail s'affiche dans le formulaire de droite. Save permet d'envoyer une requête à un SessionBean qui met à jour la donnée en base. Selon le message renvoyé par ce SessionBean (succès, erreur, ...), on met à jour côté client les données telles que sauvegardées.

L'avantage de cette solution : seules les données du formulaire de modification sont envoyées au serveur (par exemple pas besoin d'envoyer les informations d'état sur la page...), et surtout, aucun besoin de renvoyer tout le code html pour raffraîchir la liste !

Parce qu'un diagramme vaut mieux qu'un long discours voilà ce que cela donne de manière synthétique. Je ne suis pas rentré dans les détails de ce qui ce passe côté ExtJS :

La partie Faces/jsf est réduite à sa partie minimale, c'est-à-dire initialiser la page à son miminum (ce qui ne comprend même pas le chargement de la liste par exemple). Tous les événements se produidant sur la page seront traités par Seam Remoting.

Suite dans un prochain article où je montrerai le code source des classes Store, Reader, etc qui permettent de faire le lien entre ExtJS et Seam Remoting...

Vers l'article suivant : http://ntispace.blogspot.com/2008/01/seam-extjs-ext-store-reader-proxy.html