Technologies

Positionnement de Vaadin parmi les frameworks de développement Web

Publié le : Auteur: Christian CHABOT Laisser un commentaire
Vaadin MVP

Le choix d’un framework de développement pour ses applications Web est un exercice aujourd’hui ardu devant le nombre de candidats possibles, du moins si l’on n’a pas la chance de développer sous .Net 🙂 .

Parmi les frameworks de développement Web AJAX, Vaadin tient une place particulière en raison d’un choix d’architecture qui le place entre les frameworks Web traditionnels et les frameworks RIA.

Avec les frameworks utilisés dans les architectures Web traditionnelles (par ordre d’apparition JSP, Struts, Spring MVC, Apache Wicket, JSF et pardon à ceux que j’oublie ici), la page HTML est construite sur le serveur pour être interprétée et affichée par le navigateur client.
Cette approche a évolué avec la standardisation des échanges asynchrones client / serveur et des opérations de transformation du document HTML, avec pour résultat la possibilité d’interagir côté client sur les pages HTML générées avec de nombreux frameworks AJAX tels que Dojo, JQuery ou Yahoo UI.

Le RIA est l’étape ultime de cette évolution où le document HTML généré par le serveur est réduit à sa plus simple expression pour être enrichi par le navigateur client jusqu’à atteindre sa forme finale. L’essentiel de la logique de présentation (apparence, contrôle et cinématique) est ici hébergée par le client, avec pour conséquence une régression de la sécurité applicative qui va avec puisque le code JavaScript est entièrement lisible sur le navigateur (même si on peut le compresser pour compliquer sa lecture). GWT est un framework qui illustre parfaitement cette logique. Cette remarque ne vaut pas pour des frameworks RIA comme Flex ou JavaFX qui n’utilisent pas JavaScript et nécessitent des plugins sur les navigateurs pour le rendu graphique, ce qui pose d’autres contraintes que nous n’aborderons pas dans cette réflexion.

Vaadin utilise le pattern d’architecture MVVM – Model View ViewModel – qui le place entre ces deux approches. Ce pattern, diffusé par Microsoft pour le développement des applications WPF et Silverlight, introduit un représentant serveur par composant de présentation client. Au passage, ce n’est pas le seul framework AJAX de ce type puisqu’Eclipse RAP utilise ce principe.

Architecture client/serveur

Dans Vaadin, une architecture orientée serveur associée à un modèle de composants clients AJAX est utilisée pour simplifier la programmation et augmenter la sécurité des applications Web.
Une bibliothèque de composants d’interface utilisateur prêts à l’emploi est fournie avec la possibilité de créer de nouveaux composants. Les composants reposant sur une version AJAX propriétaire ont été abandonnés à la fin de l’année 2007 au profit de l’encapsulation de composants GWT ; cette transition a été facilitée par la logique de moteur de rendu graphique utilisée dans Vaadin. On utilise donc le langage Java pour la réalisation d’une application de bout en bout.
Le rendu graphique repose sur un moteur de rendu AJAX spécifique à Vaadin, qui est chargé dans le navigateur lorsque la page avec l’interface utilisateur Vaadin est ouverte. Les composants d’interface utilisateur côté serveur sont rendus en utilisant les widgets côté client, le framework gérant la sérialisation de l’état du composant de façon transparente avec un mécanisme RPC au format UIDL (JSON propriétaire) entre les deux parties. De la même façon, le modèle événementiel est partagé entre client et serveur comme le monte la figure suivante sur un clic bouton :

Vaadin Event

Le code côté serveur s’exécute dans un serveur Web Java sous la forme de servlet, ou de portlet dans un portail. Il dispose d’une API côté serveur avec des dizaines de composants pour le développement d’interfaces utilisateur.

Analyse dynamique

Prenons l’exemple de la liste de données fourni avec les échantillons d’exemples sur le site de Vaadin. Après avoir chargé la page du composant datatable page et vidé la console d’affichage, on obtient l’état suivant sous firebug :

vaadin-datatable-1

On utilise ensuite l’ascenseur pour descendre dans la liste, ce qui provoque le chargement des éléments non encore affichés (lazy loading), à savoir les drapeaux et les noms des pays affichés dans la liste :

vaadin-datatable-2

En analysant la première requête effectuée par l’application Vaadin lors de cette action de défilement dans la liste, on constante que la demande de rafraîchissement des éléments affichés est transmise au serveur en UIDL (firstToBeRendered – lastToBeRendered, firstvisible) :

vaadin-datatable-3

La réponse du serveur indique l’ensemble des valeurs à charger dans la liste pour les indexes demandés :

vaadin-datatable-4

On voit donc que Vaadin dispense les développeurs de la création des services AJAX et des formats de données qui vont avec pour la gestion des widgets. Dans une moindre mesure, cette communication UIDL renforce la sécurité applicative par la seule connaissance de la logique de présentation côté client, les logiques de contrôle et de cinématique résidant sur le serveur. La communication entre le client et le serveur ne fait plus apparaître d’information métier mais des changements d’états ou événementiels liés à la partie graphique.

Architecture applicative

Jusqu’à la version 6, une application Vaadin est construite sur le même principe qu’une application Swing à partir de composants d’interface utilisateur contenus hiérarchiquement dans les composants de mise en page. Le code d’une application Vaadin ressemble donc fortement à celui d’une application Java client lourd écrite avec Swing :

public class HelloWorld extends com.vaadin.Application {
   public void init() {
      Window main = new Window(“Hello window”);
      setMainWindow(main);
      main.addComponent(new Label(“Hello World!”));
   }
}

Cette similitude a disparu dans la dernière version 7 qui a été profondément remaniée pour être plus proche des concepts Web ; on y retrouve donc une logique intermédiaire entre la servlet et l’application client lourd :

@Title("Hello Window")
public class HelloWorld extends UI {
   @Override
   protected void init(VaadinRequest request) {
      // Create the content root layout for the UI
      VerticalLayout content = new VerticalLayout();
      setContent(content);
      // Display the greeting
      content.addComponent(new Label("Hello World!"));
   }
}

L’interface utilisateur peut être personnalisée avec des thèmes CSS, et liée aux données par un mécanisme de data binding. Vaadin reprend le pattern Model-View-Presenter Pattern de GWT pour isoler le code d’implémentation de la vue du modèle conceptuel métier :

Vaadin MVP

En revanche Vaadin ne préconise aucun pattern d’architecture pour l’organisation des couches métier, et on se retrouve de ce point de vue devant des choix de conception identiques à ceux des applications développées avec GWT, JSF ou Struts par exemple. Les traitements métiers seront donc déclenchés à partir du contrôleur à l’aide de services utilisant des DAO, ou à l’aide d’EJB suivant que l’on choisisse une architecture en couche ou une architecture en composants.

Pour aller plus loin

Ce billet n’a pas pour ambition de décrire intégralement la mise en œuvre d’une application avec Vaadin, d’autant que le travail pédagogique effectué par les auteurs de ce framework est remarquable. Je vous renvoie donc sur le « Book of Vaadin » qui est un ouvrage de qualité professionnelle proposé en téléchargement gratuit depuis le site de Vaadin dans divers formats (HTML, PDF, PDF pocket, ePub).

Il existe aussi une refcardz pour une première prise de connaissance des différents concepts. Attention pour ceux qui comme moi l’auraient déjà téléchargée, elle a évolué pour passer de la version 6 à la version 7 de Vaadin (je tiens à votre disposition la version 6 qui ne se trouve plus sur le site de refcardz 😉 )